What breaks when legacy PAM tools do not cover Kubernetes access?

Why This Matters for Security Teams

Legacy PAM was designed around humans requesting elevated access to servers, not around Kubernetes workloads that authenticate with tokens, service accounts, and short-lived credentials. That mismatch creates a gap between what teams can record and what they can actually govern. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which is why blind spots persist even in mature environments.

For Kubernetes, the real risk is not just privilege but velocity. Access can be created through namespaces, secrets, CI/CD pipelines, admission paths, and cloud IAM bindings faster than older PAM workflows can broker or revoke it. The result is a control plane that appears covered on paper while workload-level access remains outside the review cycle. Current guidance from the OWASP Non-Human Identity Top 10 treats this as an identity governance problem, not a logging problem.

In practice, many security teams discover the gap only after a cluster token, service account, or pipeline secret has already been reused outside the intended boundary.

How It Works in Practice

When PAM does not extend into Kubernetes, control tends to fragment across multiple layers. Teams may still use PAM for bastions or privileged shells, but Kubernetes access is usually mediated by kubeconfig files, cloud-issued tokens, role bindings, and workload service accounts. Those are identity objects, not traditional interactive sessions, so older vault-and-record models do not map cleanly.

The practical response is to treat Kubernetes access as part of the broader NHI lifecycle. That means identifying which humans, pipelines, and controllers can mint or reuse cluster credentials, then governing those credentials through short TTLs, scoped bindings, and automated revocation. NHI Mgmt Group’s Ultimate Guide to NHIs highlights how common exposure becomes when secrets are stored outside proper controls, and that pattern is often amplified in CI/CD-to-cluster workflows.

• Map every Kubernetes entry point, including kubectl access, service accounts, cloud IAM federation, and automation tokens.
• Use workload identity and federation where possible so the cluster can validate what the caller is, not just what secret it presents.
• Apply least privilege at the namespace, workload, and verb level instead of relying on broad cluster roles.
• Rotate and revoke tokens automatically after deployment, incident response, or job completion.
• Log the full chain of access from pipeline to cluster to downstream cloud service.

For implementation patterns, the OWASP Non-Human Identity Top 10 and Kubernetes-native identity controls should be read together, because the control failure usually sits at the boundary between infrastructure and workload identity. These controls tend to break down when clusters are federated across multiple clouds and each environment issues credentials differently, because revocation and attribution lose consistency.

Common Variations and Edge Cases

Tighter Kubernetes access control often increases operational overhead, requiring organisations to balance faster delivery against stronger credential discipline. That tradeoff becomes visible in hybrid estates, where one cluster uses cloud IAM federation, another relies on long-lived kubeconfig files, and a third still depends on manual approval through PAM.

There is no universal standard for this yet, but current guidance suggests treating exceptions explicitly. Break-glass access should be time-bound and separately monitored. Shared admin accounts should be phased out in favor of named operators and workload identities. Some environments also need read-only observability access for platform engineers, which is legitimate but still should not be confused with privileged execution rights.

Edge cases appear when legacy applications inside Kubernetes require embedded credentials or when third-party operators manage resources across clusters. In those cases, the main question is not whether PAM can record a session, but whether the identity can be constrained, rotated, and attributed end to end. The control gap is often exposed first in incident response, because revocation across cloud IAM, cluster RBAC, and application secrets does not happen in one place.

Related resources from NHI Mgmt Group

• What frameworks should guide PAM programmes that now cover NHI and operational access?
• What breaks when audit evidence is fragmented across IAM and PAM tools?
• What breaks when access across trust domains is not tightly scoped?
• What breaks when session monitoring is missing from industrial remote access?