TL;DR: A production kubeconfig that contains a certificate or token behaves as a reusable production credential, so every copy carries the same identity and access until expiry or trust removal, according to Teleport. The practical answer is individual SSO logins with short-lived credentials, because revocation mechanics differ sharply across certificates, service account tokens, and OIDC sessions.
At a glance
What this is: This is an analysis of why shared Kubernetes kubeconfigs are effectively production credentials and why revocation behaves differently for certificates, service account tokens, and OIDC sessions.
Why it matters: It matters because IAM and platform teams cannot treat copied kubeconfigs like harmless config files; the access model determines whether offboarding is immediate, delayed, or cluster-wide.
👉 Read Teleport's analysis of why shared production kubeconfigs are hard to revoke
Context
A kubeconfig is not just a pointer to a cluster endpoint. If it embeds a client certificate, private key, or bearer token, it carries the identity used to authenticate to the Kubernetes API and the permissions attached to that identity.
That creates a governance problem for Kubernetes access management: shared files create shared identities, and revocation depends on the credential type. Human access, service account access, and certificate-based access all fail differently when teams try to remove one person’s access without disrupting everyone else.
Key questions
Q: What breaks when a shared kubeconfig is copied to multiple users?
A: The file stops being a harmless configuration object and becomes a shared production credential. Every copy authenticates as the same Kubernetes identity, so revocation, audit, and accountability all collapse onto one principal. If access needs to be removed for one person, the underlying credential model must change, not just the file distribution.
Q: Why do Kubernetes client certificates outlive normal offboarding?
A: Because Kubernetes validates the certificate through trust in the signing CA and the certificate’s expiry, not through a central revocation list for each copy. Deleting the request or record does not disable the signed certificate. If the certificate is privileged, the only hard stop may be trust-anchor replacement or waiting for expiry.
Q: How should teams revoke access when a ServiceAccount token is shared?
A: Treat the ServiceAccount as the identity object and the token as a reusable authenticator. If multiple kubeconfigs carry the same token, deleting one copy does nothing. Revocation needs to happen at the service account or token-issuance boundary, with short lifetimes and clear ownership for each workload identity.
Q: Should human Kubernetes access use certificates, tokens, or SSO-based login?
A: For most human access, SSO-based login with short-lived credentials is the cleaner control model. Certificates and copied tokens are harder to revoke precisely once they spread, while session-fetched credentials let offboarding follow the identity lifecycle. Use the most ephemeral authenticator that still fits the operational workflow.
Technical breakdown
What a kubeconfig actually authenticates
A kubeconfig stores the API server address and the credentials kubectl presents when it connects. If the file contains a client certificate and key, the certificate establishes the username and group claims that the API server accepts. If it contains a bearer token, the token becomes the login. In both cases, copying the file copies the effective identity, not just the connection settings. That is why Kubernetes access control has to be understood as identity-bound, not file-bound.
Practical implication: Treat any kubeconfig with embedded credentials as a production credential, not as a configuration artifact.
Why certificate revocation is hard in Kubernetes
Client certificates are validated through the trusted certificate authority and their expiry, not by a central revocation list that Kubernetes can consult for each copy. Deleting the CertificateSigningRequest removes the record of issuance, but the signed certificate still works until it expires. If the certificate is tied to a powerful group such as system:masters, RBAC cannot narrow it after issuance. The only hard stop is trust removal, which can require CA rotation for the whole cluster.
Practical implication: Plan certificate lifetime and CA trust as revocation controls, not as afterthoughts.
How shared service account tokens and OIDC logins differ
A short-lived service account token still behaves like a copied credential when it is reused in multiple kubeconfigs, but deleting and recreating the service account changes the identity boundary and invalidates old tokens. OIDC works differently because the token is often fetched at runtime from an identity provider. That means account removal blocks the next login, while an already issued token may remain valid until its own lifetime ends. The security outcome depends on whether access is issued once and copied or fetched per session.
Practical implication: Use session-fetched credentials for human access when you need offboarding to follow the identity lifecycle rather than the file lifecycle.
Threat narrative
Attacker objective: The attacker aims to preserve or reuse cluster access through a copied Kubernetes credential that outlives the intended offboarding event.
- Entry occurs when a shared kubeconfig with an embedded certificate or token is copied to multiple users or systems, giving every copy the same authenticated identity.
- Escalation follows when that identity is mapped to broad RBAC permissions or a privileged group such as system:masters, making each copy operationally equivalent.
- Impact occurs when revocation is attempted but the copied credential remains valid until expiry, CA rotation, or identity-provider token expiry, leaving residual cluster access in place.
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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shared kubeconfigs create identity duplication, not just configuration duplication. Once a certificate or token is embedded in the file, every copy becomes the same principal to the Kubernetes API. That breaks the assumption that access can be removed per person after the file has been distributed. The practical conclusion is that the identity boundary sits inside the credential, not around the YAML.
Certificate revocation in Kubernetes exposes a lifecycle gap. The article shows that deleting issuance records does not revoke an already signed certificate, and a privileged certificate may outlive local administrative intent. That is a direct fit for OWASP-NHI guidance on long-lived secrets and improper offboarding, because trust persists until expiry or trust-anchor replacement. Practitioners should treat certificate lifetime as an exposure window, not a convenience setting.
Shared service account tokens demonstrate why file reuse is an access-control anti-pattern. The same token copied into multiple kubeconfigs gives all holders the same namespace or cluster access, and RBAC cannot distinguish the copies. This is a classic machine identity governance problem, not a Kubernetes-only quirk. Teams need to model the service account, not the file, as the governed identity object.
OIDC changes the revocation model because access can be re-evaluated at login time. A runtime-fetched credential lets account deletion stop the next session without changing cluster trust for every other user. That is the cleaner governance pattern for human access because authentication and authorization remain separable, and offboarding follows the identity provider rather than the distribution of copied files.
Kubernetes access governance should move from shared artefacts to individual identity issuance. The article reinforces a simple but stubborn truth: if access is packaged into a reusable file, revocation becomes delayed, broad, or infrastructure-wide. The more sustainable control model is individual login, short-lived credentials, and explicit lifecycle ownership for each access path.
What this signals
Identity duplication is the core risk: once Kubernetes credentials are embedded in a shared kubeconfig, the control surface shifts from users to files, and that is the wrong unit of governance. Access reviews and offboarding processes have to target the credential source, not the copied artefact.
Short-lived session credentials are the governance breakpoint: they turn Kubernetes access from a file distribution problem into an authentication lifecycle problem. That is the model that lets IAM teams align cluster access with joiner-mover-leaver workflows instead of static secret sharing.
For practitioners
- Replace shared kubeconfigs with individual identities Issue separate Kubernetes access for each user so that revocation targets one person rather than every copy of the file. Keep the cluster endpoint decoupled from the credential and bind access to the user session, not to a reusable kubeconfig.
- Treat embedded certificates as revocation-bound credentials Set certificate lifetimes deliberately and assume deletion of the issuance record will not disable the credential. If a certificate carries privileged groups, plan for expiry or trust-anchor replacement as the only reliable off switch.
- Use runtime-fetched credentials for human access Prefer SSO-backed exec plugins or proxy-mediated login flows so each session retrieves a fresh credential. That lets account disablement affect the next authentication attempt rather than every copied file already sitting on disk.
- Map RBAC to the real identity source Review whether your Kubernetes roles are attached to stable usernames and groups issued by the certificate, token, or identity provider. If the same credential can be copied, RBAC will apply uniformly to every copy, so ownership has to be fixed upstream.
Key takeaways
- Shared kubeconfigs are production credentials when they contain certificates or tokens, because every copy inherits the same Kubernetes identity.
- Revocation behaves differently across certificate, ServiceAccount, and OIDC-based access, so teams cannot assume one offboarding pattern fits all.
- Individual SSO logins with short-lived credentials are the most governable path for human Kubernetes access because they tie revocation to identity lifecycle rather than file reuse.
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, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article centers on credentials that remain valid after distribution changes or attempted removal. |
| NHI-07 — Long-Lived Secrets | The post shows that embedded certificates and tokens persist beyond the moment a user leaves. | |
| NHI-05 — Overprivileged NHI | The example admin certificate and broad system:masters access show excessive privilege on a reusable credential. | |
| Recommendation — Classify copied kubeconfigs as offboarding-sensitive credentials and retire them at the identity source. Replace long-lived kubeconfig credentials with short-lived session-issued authenticator flows. Restrict NHI permissions to the minimum cluster scope before any kubeconfig is distributed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential issuance, expiry, and replacement are the main control problem in the article. |
| AC-6 — Least Privilege | The article demonstrates the risk of broad cluster-admin style permissions attached to reusable credentials. | |
| Recommendation — Apply authenticator management controls to shorten credential lifetimes and define explicit revocation points. Enforce least privilege on Kubernetes identities so one copied credential cannot reach every namespace. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post is fundamentally about who can access the cluster and how that access is revoked. |
| Recommendation — Review Kubernetes entitlements against the actual identity source and remove stale access at issuance boundaries. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared kubeconfigs expose the account lifecycle gap that account management must govern. |
| Recommendation — Tie Kubernetes access to managed accounts and deprovision them instead of circulating shared credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Copied kubeconfigs enable credential reuse that supports unauthorized access expansion. |
| Recommendation — Map copied kubeconfigs to credential-access and lateral-movement detections in your threat model. | ||
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.
- 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.
- 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.
- Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step kubeconfig examples showing how certificates, ServiceAccount tokens, and OIDC sessions behave differently in practice
- The exact revocation tests that prove why deleting a CSR, token copy, or binding does not have the same outcome
- Kubernetes command examples for rotating trust anchors and validating whether a copied credential still works
- The full comparison of shared files versus individual access patterns for human cluster users
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management 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 or Kubernetes access programme, it is worth exploring.
Published by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
