TL;DR: Multi-cluster Kubernetes shifts the main security failure from networking to credential sprawl and audit fragmentation, according to Twingate, because identities are handed off across laptops, cloud IAM, CI and cluster-local auth before anyone can reconstruct a session. Private clusters alone do not create governance; one identity source and one audit trail do.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Multi-cluster Kubernetes access breaks at the credential and audit layer, not the network layer.
Why it matters: IAM, IGA, and platform teams need a model that preserves real user identity across clusters, providers, and sessions so offboarding and forensics stay tractable.
Context
Kubernetes access becomes a governance problem once the number of clusters grows beyond a single control plane. The technical issue is simple in plain English: the same person can end up represented by different credentials, different auth plugins, and different audit trails depending on cluster and cloud provider. That breaks both accountability and offboarding, which is why identity architecture matters more than network isolation here.
IAM and IGA basics still apply when the target is a Kubernetes cluster, but multi-cluster environments expose where those basics stop being enough. The challenge is not just authenticating a user once; it is preserving a consistent identity, entitlement model, and session record across every cluster boundary.
Key questions
Q: How do service accounts stay manageable across many Kubernetes clusters?
A: Service accounts stay manageable by being centrally named, scoped to namespaces or clusters, granted only the RBAC verbs they need, and tracked as individual identities with owners, labels, and rotation rules for any bound token or certificate. Federation patterns, admission controls, and automated lifecycle management help prevent orphaned or over-privileged service accounts across clusters.
Q: Why do bastion hosts weaken Kubernetes access governance?
A: Bastion hosts weaken Kubernetes access governance because they create a shared jump point that concentrates privileged credentials, bypasses per-user access paths, and often leaves indirect, hard-to-audit kubectl sessions. They also encourage standing access unless paired with strong MFA, short-lived credentials, session recording, and tightly scoped RBAC on the cluster API.
Q: What is the difference between GKE IAM and Kubernetes RBAC for cluster access control?
A: GKE IAM governs access at the Google Cloud layer, including who can authenticate and request a managed identity path. Kubernetes RBAC governs what that authenticated identity can do inside the cluster, such as reading pods or listing resources in a namespace. Practitioners need both layers aligned, because one without the other leaves gaps in authorization.
Q: What signs show Kubernetes access has become ungoverned?
A: Kubernetes access has become ungoverned when cluster-admin grants spread beyond named operators, kubeconfig files and bearer tokens are copied informally, service accounts lack clear owners, and audit logs show direct use of long-lived credentials. Another sign is missing JIT approval, weak RBAC boundaries, and no periodic review of namespaces, roles, and bindings.
Technical breakdown
Why kubeconfigs and bastions fail at scale
Kubeconfigs and bastion hosts concentrate privilege in places that are easy to copy, forget, or lose track of. A kubeconfig can contain long-lived credentials, while a bastion often becomes a credential repository with shell history, local context files, and ad hoc session logging. As cluster count rises, the access path becomes a chain of handoffs rather than a single governed identity event. That makes it harder to know who initiated a command and whether the credential still belongs to an active user.
Practical implication: Replace credential concentration points with access paths that preserve the original user identity from authentication through session recording.
How IdP identity maps into native Kubernetes RBAC
A workable multi-cluster model uses the identity provider as the source of truth and binds its groups directly to Kubernetes RBAC. The API server then sees a real user identity, not a shared cluster-local account or copied kubeconfig token. That matters because the entitlement decision stays centralized while the cluster enforces it locally. The design also reduces drift: if the same IdP group governs multiple clusters, privilege changes do not need to be re-implemented per environment. See the Kubernetes NHI Security Guide.
Practical implication: Bind cluster access to IdP groups rather than local accounts so authorization changes can be governed once and inherited everywhere.
Why audit trails fragment across clouds and clusters
Multi-cluster and multi-cloud access produces separate evidence sources unless the session is logged centrally. CloudTrail, Cloud Audit Logs, Azure Activity Log, bastion logs, and cluster audit records each capture part of the picture, but none of them alone reconstructs the full user session. In practice, that means incident response has to correlate identity, command, namespace, and time across systems that were never designed to agree with each other. Auditability fails when the evidence trail is distributed across providers instead of being tied to one authenticated session. See the IAM and IGA Basics.
Practical implication: Centralize session recording so one query can answer who acted, where they acted, and what command they ran.
Threat narrative
Attacker objective: The attacker or insider wants durable cluster access that is difficult to attribute, revoke, or reconstruct across environments.
- Entry begins when an operator authenticates through a cloud identity, VPN, bastion, or copied kubeconfig rather than through a single governed session path.
- Credential access occurs when static kubeconfigs, embedded tokens, or bastion-held credentials expose reusable cluster privileges across multiple environments.
- Escalation happens as the same identity is translated differently by each provider, while RBAC drift and scattered logs hide the true session owner.
- Impact is the inability to attribute destructive Kubernetes actions quickly, which slows incident response and weakens offboarding control.
Breaches seen in the wild
- TeamTNT worm 2020: A TeamTNT cryptomining worm spread through exposed Docker APIs and stole AWS credential files from every host it infected, Cado Security found.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Multi-cluster Kubernetes turns identity fragmentation into the primary control failure. The network can be perfectly segmented and still leave operators with no trustworthy answer to who executed a command. That is because the access chain now spans IdP, cloud IAM, kubeconfig, CI, and cluster-local RBAC, which turns one identity decision into several disconnected records. Practitioners should treat cross-cluster identity consistency as a core governance requirement, not an implementation detail.
Credential sprawl is the named failure mode, not a side effect. Static kubeconfigs, bastion-held keys, and provider-specific auth plugins create a state where access exists in too many places and disappears from too many logs. Joiner-Mover-Leaver guidance is relevant here because offboarding only works when every credentialized path is tied back to a single lifecycle event. The implication is that cluster access governance must be lifecycle-aware across every environment, not handled as a per-cluster exception.
Auditability collapses when session identity is not preserved end to end. A command run through a bastion, a VPN, or a provider-specific token may be legitimate, but the resulting evidence is often too fragmented to support timely accountability. That is why a multi-cluster program needs one authoritative session record that ties user, cluster, namespace, and command together. Practitioners should re-evaluate any access path that cannot produce that record on demand.
Identity must flow into Kubernetes RBAC without being laundered through local credentials. The article's operational model is directionally right because it preserves the original user identity at authorization time rather than after the fact. That reduces the number of places where privilege can drift, while making revocation and review materially simpler. For identity teams, the question is whether RBAC reflects actual human or workload identity, or merely a local proxy for it.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
- Read next: Kubernetes NHI Security Guide
What this signals
Multi-cluster programs should assume identity drift before they assume network compromise. The operational risk now sits in the gap between how a person authenticates and how the cluster records the resulting session. When that gap widens, offboarding and forensics both slow down, which is why the governance model has to move upstream to identity issuance and session attribution.
Session provenance becomes the governing concept for Kubernetes access at scale. A platform team can tolerate multiple clusters, multiple clouds, and multiple RBAC layers only if it can still prove who acted from a single authoritative record. That is the difference between access that is merely permitted and access that is actually governable.
For practitioners
- Eliminate static kubeconfigs for human admins Move administrators to session-based access that derives Kubernetes credentials from the IdP at request time, so nothing long-lived sits on laptops or bastions.
- Bind cluster RBAC to IdP groups Use the same group model across clusters and clouds so entitlement changes are made once in the identity source and inherited by every cluster.
- Centralize kubectl session recording Store the user identity, target cluster, namespace, command, and transcript in one place that your incident response team can query quickly.
- Treat bastions as temporary exceptions Limit bastions to edge cases that cannot use direct identity propagation, and remove any kubeconfig storage or shell-based audit dependency from them.
Key takeaways
- Multi-cluster Kubernetes creates an identity and audit problem when credentials, auth methods, and logs fragment across providers.
- The practical failure is not lack of segmentation; it is loss of a single, attributable session record for every action.
- Treating IdP identity as the source of truth for cluster RBAC is the control shift that makes offboarding and investigation manageable.
Related NHI Mgmt Group resources: Kubernetes NHI Security Guide · Joiner-Mover-Leaver (JML) Guide · Access Request and Approval Workflow Design Guide · Kubernetes Security Guide
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Static kubeconfigs and shared cluster credentials create excessive standing access across clusters. |
| NHI-07 — Long-Lived Secrets | The article centers on long-lived kubeconfig tokens and cached credentials on endpoints and CI. | |
| Recommendation — Reduce standing Kubernetes access by binding permissions to short-lived identities and limiting cross-cluster privilege. Replace long-lived cluster secrets with session-bound credentials and revoke them when the identity session ends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Kubeconfig tokens and cluster credentials are authenticators that need lifecycle control and rotation. |
| Recommendation — Apply authenticator lifecycle controls so Kubernetes credentials are issued, rotated, and revoked under policy. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece is fundamentally about keeping access permissions consistent across clusters and providers. |
| Recommendation — Map cluster permissions to governed entitlements and keep authorization decisions consistent across environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked kubeconfigs and bastion-held credentials create pathways for credential access and cluster-to-cluster movement. |
| Recommendation — Hunt for reusable Kubernetes credentials and restrict movement paths that let one access point reach many clusters. | ||
Key terms
- Kubeconfig: Kubeconfig is the file Kubernetes uses to store cluster connection details and authentication information. If it is exposed, world-readable, or synced insecurely, an attacker may gain access to the cluster. Strong file permissions and careful handling are essential because it directly governs administrative reach.
- Cluster Audit Log: A cluster audit log is the record of security and administration events produced by a Kubernetes cluster. It captures API requests, user and service account identities, verbs, objects, and response outcomes, so administrators can trace who accessed what, detect privilege misuse, and support incident investigation and compliance review.
- Kubernetes RBAC: Kubernetes RBAC is the permission system that decides what users, groups, and service accounts can do inside a cluster. It uses roles and cluster roles, then binds them to subjects so access is limited to specific resources, verbs, and namespaces, reducing unnecessary control over workloads and infrastructure.
- Bastion Host: A bastion host is an intermediary system used to reach protected internal resources. It centralises entry but also concentrates trust and availability risk, which means the design only works well when logging, offboarding, and recovery are tightly controlled.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org