Topic starter
30/09/2026 5:00 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “How to Eliminate Shared Production Kubeconfigs”.
Key questions
Q: What breaks when a shared kubeconfig contains a certificate or token?
A: A shared kubeconfig turns into a reusable production credential.
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.
Q: How should teams handle human access to Kubernetes clusters?
A: Use individual SSO logins with short-lived credentials instead of shared kubeconfigs.
Practitioner guidance
- 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.
Bottom line: A kubeconfig that embeds a certificate or token behaves like a production credential, so every copy inherits the same authenticated identity.
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
👉 Read Teleport's analysis of why shared kubeconfigs are hard to revoke →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/09/2026 5:00 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Shared kubeconfigs turn Kubernetes access into a production credential