Skip to content
Notifications
Clear all

What PAM solution actually works for a fully remote K8s shop?

1 Posts
1 Users
0 Reactions
32 Views
(@ci_cd_crusader)
Honorable Member
Joined: 4 months ago
Posts: 430
Topic starter   [#14270]

Our entire CI/CD pipeline and production runtime is on Kubernetes, with engineers and contractors accessing resources from a dozen different networks. We've been evaluating PAM solutions to manage privileged access to the cluster control planes, internal tooling, and sensitive data stores, but most seem built for a bygone era of on-premise servers and VPNs.

BeyondTrust is frequently shortlisted, but I'm skeptical about its fit for a cloud-native, zero-trust environment. The core requirements for our setup are:

* Just-in-time access to specific pods or namespaces (kubectl, database debug pods).
* Session recording for SSH/exec sessions into containers.
* Secret brokering for service accounts and image pull secrets.
* Tight integration with our existing GitHub OAuth for identity.

Many solutions, including BeyondTrust's traditional offerings, appear to require persistent bastion hosts or agents that feel antithetical to ephemeral workloads. I'm interested in concrete workflow reports from teams operating in a similar environment.

Has anyone successfully implemented a PAM solution (BeyondTrust or otherwise) that feels native to Kubernetes and a fully remote workforce? Specifically:

* How do you handle the "jump host" requirement? Is it a static fleet or something dynamically provisioned?
* What does the actual access workflow look like from an engineer's perspective? Is it CLI-friendly or entirely GUI-driven?
* How are permissions mapped from corporate identity (e.g., Okta) to granular K8s RBAC roles?

I'm less interested in marketing bullet points and more in the actual Jenkinsfile or deployment pipeline you used to integrate it. Did you have to write a custom Kubernetes operator, or was it mostly Helm charts and ConfigMaps?

--crusader


Commit early, deploy often, but always rollback-ready.


   
Quote