Everyone seems to default to the usual PAM suspects when discussing cloud-native infrastructure, as if ticking a compliance box is the same as securing a dynamic environment. We're a fully remote team managing dozens of Kubernetes clusters across multiple clouds, and the classic PAM playbook—vaults, jump hosts, session recording for Windows servers—feels like trying to use a brick as a doorstop for a sliding glass door.
Our actual needs are depressingly specific:
* Privileged access to cluster control planes (EKS, AKS, GKE).
* Just-in-time elevation for CI/CD pipelines deploying to production namespaces.
* Securing service accounts with overly permissive tokens.
* All access logged and tied to an individual, not a shared credential, without forcing engineers through a 10-click VPN-and-jump-host obstacle course that they'll just work around.
BeyondTrust gets mentioned, but its heritage is all over the dashboard. It feels like it's bolting cloud support onto a model designed for on-prem server racks. The "session recording" for a `kubectl exec` or a `helm upgrade` is a different beast entirely.
So I'm genuinely asking: what's actually working for shops like ours? Not the marketing sheet, but the gritty reality of integrating with our actual stack—ArgoCD, Terraform Cloud, Okta. Did you manage to make a legacy PAM solution bend to this, or did you find something built with a cloud-native first mentality? Bonus points for solutions that don't require a dedicated team of three just to keep it running.
Show me the data
You've nailed the core disconnect. Everyone sells a vault for static SSH keys, but that model breaks when your "servers" are ephemeral pods and your "admins" are automated pipelines.
We hit the same wall and ended up building a workflow around two pieces that actually understand Kubernetes identities. First, we use a cloud-native secrets operator that can do just-in-time credentials for service accounts, tied to short-lived OIDC tokens from our CI. It treats the cluster API as the endpoint, not a server to SSH into. Second, we paired it with an internal tool that brokers kubectl exec sessions by generating ephemeral certificates, logging the human's identity from our IDP directly in the Kubernetes audit logs.
The painful part was accepting that no single vendor product gave us both. We had to stitch together the pipeline access piece and the human access piece separately, but at least both flows now land in the same audit trail.
buyer beware, but buy smart
You're right about the legacy PAM vendors. Their session concept is rooted in a GUI or SSH connection to a static host, which maps poorly to API-driven, multi-cluster operations.
We found focusing on Kubernetes-native audit trails gave us the individual accountability we needed, without trying to retrofit "session" recording. We enforce that all human access, even through kubectl, must flow via an OIDC proxy that injects the user's identity into the cluster's audit logs. For pipelines, we issue short-lived, auto-rotated tokens bound to the specific CI job ID. This approach flips the model: instead of a PAM tool being the gate, the cluster itself becomes the gatekeeper, logging every action with a verified identity.
The vendor landscape is still catching up, but look at tools that treat the service account token problem as a first-class concern. They should automate the lifecycle of those credentials, not just vault them.
You've perfectly described the square peg, round hole problem. The marketing push for "cloud PAM" often just adds a web interface to the same credential vault model, which fundamentally misunderstands what a cluster control plane is.
My team encountered the same frustration and landed on a similar approach to what user1411 hinted at, but with a critical caveat regarding the audit trail. Relying solely on Kubernetes audit logs for accountability can leave gaps during incident response, because the logs show the *identity* but not the full *intent* behind a series of commands in a `kubectl exec` shell. We needed something that could reconstruct the procedural chain.
We ended up integrating a Kubernetes-native proxy that brokers all `kubectl` and pipeline access, but we also mandated that all privileged service account tokens be dynamically provisioned via a secrets operator that ties each token to a specific Git commit SHA and pipeline run ID. This creates a non-repudiable link back to the exact code and intent, which the cluster audit log alone doesn't provide. The tool that finally worked for us treats the cluster API as the only true perimeter.
—at
That link back to a Git commit SHA is a fantastic addition. It's something we realized we needed after a "why was this pod deleted?" incident where the audit log only showed the pipeline service account.
Our solution was similar - we set up our GitLab CI jobs to automatically inject the commit SHA and pipeline URL as environment variables into any kubectl context used by the job. That way, the audit log shows the service account, but our internal logging slurps those variables and ties the action directly to the merge request. It closes the loop.
It does add a tiny bit of complexity to the pipeline definitions, but the forensic clarity is 100% worth it.
Pipeline Pilot
Forget vendors for a second. The real question is why you'd even want "session recording" for an API-driven system. That's a server-centric concept they're trying to upsell you.
You're right about BeyondTrust and its kind. They're selling doorstop bricks because that's what's in their warehouse. The audit trail you need is already in the cluster - the problem is making it useful and tying it to intent, which they can't do.
Look at the procurement angle instead. Every vendor pushing "cloud PAM" is just reselling vault licenses and calling it a feature. The lock-in comes when you realize their entire model depends on being the credential gatekeeper for a world that doesn't use static credentials. Don't buy a gate; build an identity bridge.
Trust but verify.