TL;DR: Teleport argues that a production kubeconfig containing a certificate or token behaves as a reusable credential, so every copied file carries the same Kubernetes identity until expiry or trust removal. Individual SSO logins and short-lived credentials change revocation from a cluster-wide problem into a user-level control.
At a glance
What this is: This is an analysis of why shared kubeconfigs act like production credentials, with certificates, ServiceAccount tokens, and OIDC sessions each revoking differently.
Why it matters: It matters because Kubernetes access governance depends on whether identity can be revoked per person, per token, or only by changing trust for the whole cluster.
👉 Read Teleport's analysis of why shared kubeconfigs are hard to revoke
Context
A kubeconfig is not just a pointer to a Kubernetes cluster. If it contains a client certificate or bearer token, it also carries the authentication material that proves who the API server thinks the caller is, which makes sharing the file an identity problem rather than a convenience issue.
The governance gap is revocation. Certificates, ServiceAccount tokens, and OIDC-backed logins do not all fail closed in the same way, so the same file can behave like a durable production credential in one case and a short-lived, user-specific login in another.
For Kubernetes access programmes, the practical question is not whether kubectl still works after a copy is made, but whether access can be removed for one person without disrupting everyone else who inherited the same kubeconfig.
Key questions
Q: What breaks when a shared kubeconfig contains a certificate or token?
A: A shared kubeconfig turns into a reusable production credential. Every copy authenticates as the same Kubernetes identity, so deleting one file, one CSR, or even one role binding may not remove access from the other copies. The practical failure is that revocation becomes tied to the credential type, not the person who copied it.
Q: Why is Kubernetes certificate access harder to revoke than people expect?
A: Because the certificate remains valid until it expires or the cluster stops trusting the signing certificate authority. RBAC can remove permissions from that identity, but it cannot cancel the signed certificate itself. If the same CA is used broadly, revocation can require trust changes that affect more than the intended user.
Q: How should teams handle human access to Kubernetes clusters?
A: Use individual SSO logins with short-lived credentials instead of shared kubeconfigs. That gives each person a distinct identity, narrows the lifetime of the credential, and makes offboarding a user-level action rather than a cluster-wide trust event. Shared files should be the exception, not the default.
Q: What is the difference between RBAC and credential revocation in Kubernetes?
A: RBAC decides what an already authenticated identity may do, while credential revocation decides whether that identity can still authenticate at all. Removing a RoleBinding can stop permissions immediately, but a copied certificate or token may still log in. Teams need both controls, and they solve different problems.
Technical breakdown
Why a kubeconfig copy becomes a real Kubernetes credential
A kubeconfig can hold three different things: the cluster endpoint, the trust anchor used to validate the API server, and the client credential used to authenticate the caller. When the file includes a certificate or token, copying it duplicates the identity material, not just configuration. The API server then sees each copy as the same username and group membership, so authorisation is applied to the credential, not the human holding the file. That is why a shared kubeconfig turns into a reusable production credential rather than a harmless config artefact.
Practical implication: Treat any kubeconfig with embedded auth material as a credential that needs lifecycle control, not as a config file.
Why certificates are hard to revoke without changing trust
A client certificate remains valid until it expires or until the cluster stops trusting the certificate authority that signed it. Kubernetes does not natively maintain a practical per-certificate revocation list for these client credentials, so deleting the request record or removing an RBAC binding does not invalidate the signed certificate itself. In environments where the same CA also supports other internal clients, revocation becomes more expensive because the fix is not selective. The control boundary is therefore trust in the CA, not the presence of a record in the API server.
Practical implication: Use short-lived certificates and separate trust domains so revocation does not require replacing cluster-wide trust.
Why ServiceAccount tokens and OIDC sessions revoke more cleanly
ServiceAccount tokens and OIDC-based logins separate identity from long-lived embedded trust in different ways. A short-lived token can expire on its own, and an OIDC flow can stop minting new access once the upstream account is disabled, even if an already issued token still has time left. That means the revocation model is closer to blocking the next credential issuance than cancelling an already copied file. Kubernetes still authorises based on the verified identity claims, but the access window is narrower and more governable than a shared client certificate.
Practical implication: Prefer login flows that issue short-lived, individually owned credentials over shared embedded tokens.
Threat narrative
Attacker objective: Maintain durable Kubernetes access through a copied credential that cannot be selectively revoked.
- Entry occurs when a kubeconfig with embedded certificate or token is copied to another user or system, giving every copy the same Kubernetes identity.
- Credential abuse follows because the API server accepts each copy as the same authenticated subject until the credential expires or trust is removed.
- Impact is that revocation becomes coarse-grained, so one lost file can preserve access for all holders of the shared credential.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shared kubeconfigs create an identity persistence problem, not a file-sharing problem. The article shows that once a certificate or token sits inside the kubeconfig, every copy inherits the same authenticated subject. That breaks the usual assumption that access can be managed per user or per device. The practitioner conclusion is that Kubernetes access should be governed as credential lifecycle, not workstation configuration.
Certificate-based kubeconfig access exposes a revocation gap that RBAC cannot solve. RBAC can remove permissions from a verified identity, but it cannot cancel the underlying certificate that keeps presenting that identity. That means the real control failure is persistence of the authenticating credential after the human relationship changes. The practitioner implication is to separate authorization changes from credential invalidation, because they are not the same control plane.
Shared production kubeconfigs are a form of standing privilege. The file can outlive the access decision that created it, especially when the same certificate authority is trusted across multiple internal clients. This is the kind of lifecycle overlap that makes offboarding brittle and exception handling expensive. The practitioner conclusion is to minimise reusable cluster credentials wherever human access is involved.
Short-lived, individually issued credentials are the governance boundary Kubernetes teams actually need. The article’s OIDC example shows that access removal works best when each person gets a separate login that stops issuing new credentials after account removal. That does not eliminate every residual token window, but it changes revocation from cluster-wide trust surgery into user-level lifecycle management. The practitioner takeaway is to design for per-user issuance, not shared file distribution.
Identity blast radius is the right concept for shared kubeconfigs. A copied kubeconfig expands the impact of every trust decision because one credential can serve many users until expiry. In practice, the blast radius is governed by credential type, not by how carefully the file is distributed. Teams should treat embedded certificates and tokens as high-blast-radius assets and reserve them for tightly controlled administrative cases only.
What this signals
Shared kubeconfigs are really shared identities. Once a certificate or token is embedded in the file, the access path no longer belongs to a person, it belongs to the credential itself. That is why Kubernetes access governance should be measured by revocability, not by whether the file was distributed carefully.
Identity persistence is the hidden risk in Kubernetes admin workflows. A copied credential can survive the change that was supposed to remove access, which means offboarding and trust changes have to be tested against the actual credential type. Kubernetes teams should map where authentication still outlives organisational intent.
For practitioners
- Audit embedded kubeconfigs for production credentials Inventory kubeconfigs that contain client-certificate-data, client-key-data, or token fields, then classify each file by whether it can be revoked per user or only by changing shared trust.
- Replace shared certificates with individual login flows Move human cluster access to per-user SSO with short-lived credentials so each person has a distinct identity and access removal does not affect other holders.
- Separate cluster trust from human access Avoid reusing the same certificate authority for admin kubeconfigs and internal clients where possible, because revoking a copied admin credential may otherwise require cluster-wide trust replacement.
- Use ServiceAccount tokens only with tight lifecycle controls If a ServiceAccount token must be used, scope it narrowly, keep its lifetime short, and assume deleting one file copy will not revoke the others until the credential itself expires or is recreated.
- Validate offboarding against the credential type Test whether removing a user, role binding, CSR, or CA actually stops the specific kubeconfig copy in question, because each mechanism affects a different layer of access.
Key takeaways
- A kubeconfig that embeds a certificate or token behaves like a production credential, so every copy inherits the same authenticated identity.
- RBAC can reduce what that identity can do, but it does not necessarily invalidate the underlying credential or stop other copies from working.
- Kubernetes teams should prefer per-user SSO and short-lived credentials because revocation works far better when access is issued individually.
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-01 — Improper Offboarding | Copied kubeconfigs keep working after the human relationship changes. |
| NHI-05 — Overprivileged NHI | The admin certificate in the example grants unrestricted cluster access. | |
| NHI-07 — Long-Lived Secrets | Certificates and tokens in kubeconfigs outlive the moment they were copied. | |
| Recommendation — Inventory kubeconfig offboarding paths and remove access by credential type, not by file copy. Reduce cluster-admin exposure for embedded kubeconfig credentials and scope access by role. Replace reusable kubeconfig secrets with short-lived, individually issued credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is about lifecycle and revocation of authenticators. |
| Recommendation — Apply authenticator lifecycle controls to rotate, expire, and invalidate Kubernetes credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Kubernetes access depends on verified identity claims and permission scope. |
| Recommendation — Align Kubernetes access decisions with verified identities and tightly governed entitlements. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | A copied kubeconfig provides reusable credential access across cluster permissions. |
| Recommendation — Map shared kubeconfig risk to credential access and lateral movement monitoring. | ||
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.
- Bound Service Account Token: A service account token that is tied more closely to a specific pod or workload context. This binding improves traceability and reduces the usefulness of a stolen token, because the token is less transferable and easier to constrain to its intended runtime scope.
- Client Certificate Authentication: A method of proving a device or user possesses a trusted private key and certificate during connection setup. In identity programmes, it functions as an authentication credential, but its security depends on how tightly issuance, storage, renewal, and revocation are governed across the endpoint lifecycle.
- OIDC Authentication: OIDC authentication is an identity layer on top of OAuth 2.0 that lets systems authenticate users or workloads through a trusted identity provider. For remote MCP servers, it supports federated login, token management, and policy enforcement without embedding long-lived credentials directly into workflows or configuration files.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step kubeconfig parsing examples that show exactly which fields carry trust and authentication
- Hands-on demonstrations of certificate, ServiceAccount token, and OIDC revocation behaviour in Kubernetes
- The full lab sequence for rebuilding kubeconfigs and observing how access changes after each control is removed
- Operational guidance on when a full CA rotation becomes necessary to invalidate copied admin credentials
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 September 30, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org