Traditional PAM fails when it only governs long-lived servers and user sessions while Kubernetes access is mediated through cluster roles, tokens, and workload-level permissions. In that model, the PAM layer can still protect legacy resources, but it does not fully govern the platform where modern operations actually happen. The result is split visibility and uneven revocation.
Why Traditional PAM Stops at the Cluster Boundary
Traditional PAM was built to govern privileged users, servers, and sessions. Kubernetes changes the control plane: operators often authenticate through cluster roles, short-lived tokens, and API-driven automation rather than a fixed server list. That means the platform can be secure in parts while the actual Kubernetes access path remains outside the PAM model.
In practice, the failure is not that PAM disappears, but that it becomes incomplete. If the control only sees the legacy estate, it cannot describe who can create, modify, or delete cluster resources, nor can it reliably connect those permissions to the identities actually using them.
For teams comparing legacy PAM with modern cloud privilege, NHIMG’s Cloud PAM and CIEM Guide is useful because it shows why effective permissions and escalation paths matter more than static account lists.
When the access model shifts from host logons to cluster APIs, the security question changes from “who can log into this server?” to “who can act on this namespace, workload, secret, or admission path?” Traditional PAM usually was not designed to answer that question on its own.
What Kubernetes Access Adds That PAM Often Misses
Kubernetes access is usually mediated by role bindings, service accounts, tokens, kubeconfig files, and workload-level permissions. Those objects can grant very broad operational reach even when no interactive admin session exists. The result is a control gap between human privileged access and platform authorization.
That gap is especially visible when access is delegated to automation. A build system, deployment pipeline, or controller may hold Kubernetes permissions that are operationally equivalent to privilege, but those permissions are not governed like a classic privileged session. Service Account Security Guide is a relevant companion because service accounts, managed identities, and governance are often where Kubernetes control actually lives.
The same issue appears in token handling and credential scope. A PAM tool may manage a vaulted password for a bastion host, yet the Kubernetes cluster still accepts a bearer token, client credential, or long-lived kubeconfig with far wider reach. In that case, the PAM workflow is protecting the wrong choke point.
For the access-pattern side of this problem, Just-in-Time Access and Zero Standing Privilege Guide maps well because Kubernetes teams usually need ephemeral, auditable elevation rather than standing cluster admin rights.
How to Close the Gap Without Treating Kubernetes Like a Server
The practical fix is to govern Kubernetes as a platform authorization problem, not as a server-only privileged access problem. PAM still has value, but it needs to sit alongside cluster RBAC, token lifecycle, secret handling, and session visibility so the control surface matches how access is actually exercised.
That usually means aligning privileged access reviews to cluster-admin roles, service accounts, and namespace-scoped permissions, then checking whether those rights are time-bound, attributable, and revocable. If a team cannot show that a Kubernetes permission can be discovered and removed quickly, the access model is already outpacing the PAM model.
Teams that want a broader operating model should use Privileged Access Management Guide to separate vaulting, session control, and JIT patterns from legacy-only assumptions.
For clusters specifically, the best outcome is usually a layered model: PAM for human elevation and break-glass paths, Kubernetes-native authorization for workload and operator actions, and continuous review of the effective permissions that arise from roles, bindings, and tokens.
Risk and Threat Considerations
When Kubernetes access sits outside PAM, the main risk is privilege that cannot be seen, bounded, or revoked through the same workflow used for legacy systems. That creates uneven revocation, stale permissions, and a larger blast radius if tokens, kubeconfigs, or role bindings are abused.
Failure mechanism: Teams protect servers and interactive sessions, but attackers or insiders operate through cluster roles, service accounts, or tokens that bypass the PAM control path. Once those credentials are valid, the platform may allow workload takeover, secret access, or lateral movement inside the cluster.
Impact: Revocation becomes partial, incident response slows down, and the organisation may believe it has privileged access control when Kubernetes permissions are still effectively standing access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Kubernetes service accounts and tokens are service authentication material. |
| AC-6 — Least Privilege | Kubernetes roles and bindings must be constrained to minimum required access. | |
| IA-5 — Authenticator Management | Kubernetes tokens and kubeconfigs require lifecycle control, rotation, and revocation. | |
| Recommendation — Apply IA-9 to govern service and workload credentials that access the cluster. Use AC-6 to right-size cluster permissions and reduce standing privilege. Use IA-5 to manage token issuance, rotation, and revocation for cluster access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Kubernetes access needs policy and governance beyond legacy PAM boundaries. |
| A.8.2 — Privileged access rights | Cluster-admin and broad namespace rights are privileged access that needs governance. | |
| A.8.5 — Secure authentication | Cluster logins, tokens, and automation credentials must authenticate securely. | |
| Recommendation — Define access-control policy for cluster roles, tokens, and administrative paths. Review and restrict privileged Kubernetes rights on a scheduled basis. Enforce strong authentication for Kubernetes admin and automation access. | ||
Practitioner Guidance
What to prioritise: Start with the Kubernetes identities and permissions that can change the platform, not with the bastion or server admin accounts that PAM already covers. Cluster-admin, namespace-admin, service accounts with broad rights, and long-lived tokens deserve first review.
What to verify: Check whether every privileged Kubernetes action is attributable to a person, automation system, or workload, and whether that access can be revoked without touching unrelated legacy PAM workflows. If you cannot trace the effective permission, you do not yet have complete control.
Practitioner takeaway: Traditional PAM is still useful, but Kubernetes demands a parallel authorization model, because the real privilege often lives in cluster-native roles and tokens rather than in the session layer.
Related resources from NHI Mgmt Group
- How should security teams decide whether JIT access is safe for non-human identities?
- How should security teams evaluate PAM for cloud and Kubernetes access?
- How should security teams rethink privileged access when traditional PAM leaves gaps in coverage and onboarding?
- How should teams secure non-human identities across cloud and SaaS?