Kubernetes often uses tokens, service accounts, and ephemeral access patterns that do not fit a classic privileged-session model. Legacy PAM can still help with some credentials, but it may not describe or govern the full runtime access path. That leaves container privilege partially visible and only partially controlled.
Why Kubernetes Creates a PAM Mismatch
Kubernetes changes the access model from a human-centric privileged session to short-lived, API-driven, and workload-mediated access. That means classic PAM assumptions, such as a named admin opening an interactive session against one target at a time, do not fully describe how control flows through clusters, namespaces, service accounts, tokens, and controllers.
The result is not that PAM becomes useless, but that it often covers only the credential fragments that sit around the cluster, not the runtime relationships inside it. A team may still vault a kubeconfig or rotate a password, while the larger question, who or what can invoke an action inside the cluster, remains governed elsewhere.
Kubernetes also introduces a different trust boundary. Access can be created by deployment manifests, RBAC bindings, admission settings, and cloud IAM integrations, then inherited by pods and automation at runtime. That makes identity governance more distributed than in a legacy server estate, so a PAM programme built mainly around interactive administrative access will miss some of the effective privilege surface.
Where Legacy PAM Still Helps, and Where It Stops
legacy pam still matters for human administrator access, break-glass workflows, and the secrets that let operators reach supporting systems. It is useful when the main problem is credential storage, checkout, rotation, session recording, or privileged approval around a person logging into an administrative endpoint.
It stops short when privilege is expressed as an API token, a projected service account token, a mounted secret, or a cloud role assumption path that is consumed non-interactively by the platform. In those cases, Privileged Access Management Guide remains a useful reference for the control model, but the operational reality in Kubernetes is closer to workload access governance than to classic session brokering.
This is why many environments need PAM plus adjacent controls. PAM can govern the human side of privilege, while Kubernetes-native controls, cloud entitlement review, and secret hygiene govern the machine side. The gap appears when teams assume one control plane explains the entire runtime access path.
What “Partial Visibility” Means in Practice
Partial visibility usually shows up in three places: who owns a credential, how long it lives, and what it can actually do once admitted to the cluster. A token can be rotated, yet still grant broad namespace or cluster-wide authority. A service account can be documented, yet its downstream use by jobs, controllers, or sidecars can remain poorly understood.
That is why Kubernetes frequently exposes blind spots that legacy PAM was never designed to illuminate. The privileged action may happen through a pod, not a person; through an admission path, not a login; or through an inherited role, not a session the PAM tool can inspect. NHIMG’s Service Account Security Guide is helpful here because it treats service accounts and managed identities as first-class governance objects rather than as incidental credentials.
In containerised platforms, this becomes a control-design problem, not just a tooling problem. The question is whether the organisation can inventory workload credentials, understand their blast radius, and constrain them to the smallest practical scope across namespaces, clusters, and connected services.
Risk and Threat Considerations
When Kubernetes privilege is only partially visible, attackers can target the least governed part of the path, often a service account token, overbroad RBAC binding, or exposed secret. The risk is amplified because one compromised workload credential may unlock lateral movement inside the cluster or access to cloud resources beyond it.
Failure mechanism: A legacy PAM programme may protect operator logins while leaving runtime tokens, mounted secrets, or service account permissions outside its review and session controls. Once that happens, privilege can be reused, inherited, or replayed without the controls that PAM normally applies to human access.
Impact: The organisation gets a false sense of coverage, then discovers that container privilege is still available to an attacker, an overprivileged workload, or an automation path that never passed through PAM at all.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Kubernetes workload tokens and service accounts are non-human auth paths. |
| NHI-05 — Overprivileged NHI | Kubernetes roles and service accounts often exceed the minimum needed privilege. | |
| NHI-07 — Long-Lived Secrets | Legacy PAM gaps widen when Kubernetes credentials persist beyond their useful life. | |
| Recommendation — Harden workload authentication and eliminate weak token handling paths. Right-size service account and workload permissions to the minimum required. Replace long-lived cluster secrets with short-lived, tightly governed credentials. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Covers non-human and external authentication paths used by workloads and services. |
| AC-6 — Least Privilege | Kubernetes privilege gaps often come from excessive RBAC and inherited permissions. | |
| IA-5 — Authenticator Management | Addresses lifecycle handling of tokens and secrets used by clusters and automation. | |
| Recommendation — Apply strong authentication controls to service-to-service and workload access. Restrict Kubernetes and cloud permissions to the minimum necessary. Rotate, revoke, and protect workload authenticators on a defined schedule. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control must cover both human and workload paths in Kubernetes environments. |
| A.8.5 — Secure authentication | Kubernetes relies on tokens and service account authentication beyond classic PAM. | |
| Recommendation — Define and enforce access rules that include cluster workloads and admins. Use secure authentication methods for cluster and workload access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Kubernetes service accounts and privileged accounts need full lifecycle management. |
| Recommendation — Inventory, review, and remove stale privileged and service accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Maps to the core gap between human PAM and Kubernetes runtime privilege. |
| Recommendation — Extend identity and access control to Kubernetes workload paths. | ||
Practitioner Guidance
What to verify: Separate human admin access from workload access in your control design. If the same process is being used to describe both, your programme is probably undercounting the Kubernetes privilege surface.
Decision rule: If a Kubernetes identity can authenticate or authorize actions without a human session, treat it as runtime privilege governance, not as a PAM-only problem. That usually means you need inventory, least privilege review, secret handling, and workload-specific access controls in addition to PAM.
What good looks like: You can answer three questions for every cluster credential or role: who owns it, where it is used, and what limits its blast radius. If any one of those answers is missing, the access path is not fully governed.
Practitioner takeaway: Kubernetes does not eliminate PAM, but it changes what must be governed. The mature pattern is to use PAM for human privileged access and add workload-centric controls for the ephemeral, token-driven, and inherited privilege that PAM alone cannot fully see.
Related resources from NHI Mgmt Group
- Why do telecom regulations expose gaps in traditional IAM and PAM programmes?
- What breaks when legacy PAM tools do not cover Kubernetes access?
- Why do telecom environments expose gaps in traditional IGA and PAM coverage?
- Why do software supply chain threats expose gaps in traditional application security programmes?