Topic starter
30/09/2026 5:00 pm
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.
NHIMG editorial: based on content published by Teleport: How to Eliminate Shared Production Kubeconfigs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Treat embedded certificates as revocation-bound credentials Set certificate lifetimes deliberately and assume deletion of the issuance record will not disable the credential.
- Use runtime-fetched credentials for human access Prefer SSO-backed exec plugins or proxy-mediated login flows so each session retrieves a fresh credential.
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
👉 Read Teleport's analysis of why shared production kubeconfigs are hard to revoke →
Shared kubeconfigs: why Kubernetes access is harder to revoke?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
30/09/2026 5:00 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Shared kubeconfigs turn Kubernetes access into a production credential
