Leaked Kubeconfig Response: Contain Cluster Access From an Exposed Kubeconfig

A leaked kubeconfig file can hand a stranger the same access to a Kubernetes cluster that its owner had, and the right response depends entirely on which kind of credential sits inside it. A kubeconfig is just a YAML file that tells kubectl which API server to talk to and how to authenticate, so it may hold an embedded client certificate and key, a static bearer token, a service account token, or only an exec plugin command that fetches short-lived credentials from a cloud identity. Each of those is revoked in a different way, and one of them cannot be revoked at all short of rotating the cluster certificate authority. This guide is for platform, SRE and incident response teams who have just found a kubeconfig in a public repository, a paste site, a CI log, a support ticket or a laptop image. It covers how to identify the credential type within minutes, contain it in the right order, check the audit trail for use, and recover without breaking every legitimate client. For a cluster you already believe is compromised, move to the full Kubernetes Cluster Compromise Playbook.

Key takeaways

• Read the users block first. Whether the file holds client-certificate-data, token, or an exec section decides every later step, so open the file and classify it before touching the cluster.
• Client certificates cannot be revoked. The Kubernetes documentation states that it does not support certificate revocation and that an issued certificate stays valid until it expires, so a leaked admin certificate usually means rotating the cluster CA.
• Exec plugin files move the problem to the cloud identity. An EKS, AKS or GKE kubeconfig that only calls a plugin holds no secret of its own; check whether the cloud credentials that the plugin uses leaked alongside it.
• Remove the authorisation while you prepare the revocation. Deleting RoleBindings and ClusterRoleBindings for the leaked identity buys time, but it does nothing for certificates in the system:masters group, which bypasses RBAC.
• Prove use or non-use from the audit log. Search API server audit events for the leaked username, groups, source IPs and user agents from the moment of exposure, and keep that evidence before logs roll over.

How the incident shows up

Kubeconfig leaks are almost always found as a file or a pasted block of YAML rather than by a cluster alert. The structure is easy to recognise: top-level clusters, users and contexts lists, a current-context, and a server: URL pointing at an API endpoint, often on port 443 or 6443. The Kubernetes documentation notes that kubectl looks for a file named config in $HOME/.kube by default and that the KUBECONFIG environment variable or --kubeconfig flag can point elsewhere, which is why the file turns up under many names.

The Kubernetes project also warns that a specially crafted kubeconfig can lead to code execution or file exposure, so only open untrusted files as text, never by pointing kubectl at a file you received from outside.

Triage questions

Answer these in the first 30 minutes. Work from a copy of the file viewed as plain text.

1. Which credential type is in each user entry? Use the table below. A single file can hold several users and clusters.
2. Which cluster and environment? Match the server URL and the CA data to a known cluster. Production, shared platform and management clusters come first.
3. Is the API endpoint reachable from the internet? A private endpoint lowers the immediate risk but does not remove it; insiders and compromised hosts on the network can still reach it.
4. What identity does it map to? For certificates, decode the subject: the common name (CN) is the username and organisation (O) values are groups. Check for system:masters or kubeadm:cluster-admins.
5. When was it first exposed, and is it still exposed? The commit date, paste time or artefact upload date sets the start of your audit log search window.
6. What else leaked with it? A kubeconfig in a dotfiles repository often sits next to cloud CLI credentials, SSH keys and .env files.

Containment priorities

Contain in this order. Each step is safe to take before the next is ready.

1. Stop further exposure. Make the repository private or remove the file, take down the paste, purge the CI artefact. This does not undo the leak: assume anything public for even a few minutes has been copied.
2. Remove authorisation for the leaked identity. List RoleBindings and ClusterRoleBindings whose subjects match the username, groups or service account and delete or edit them. For managed clusters, remove the cloud mapping too: delete the EKS access entry for the IAM principal, or remove the Entra group or Azure role assignment on AKS. This step is fast and reversible.
3. Revoke what can be revoked. Delete a Secret-based service account token, delete the service account if it is single-purpose, remove a static token from the token file, delete a bootstrap token, or disable the identity provider account and revoke its sessions. The Kubernetes documentation notes that with --service-account-lookup enabled, tokens deleted from the API are revoked.
4. Decide on CA rotation for certificates. If the leaked certificate carries system:masters (kubeadm's super-admin.conf) or any long-lived admin identity, RBAC changes do not help: the Kubernetes RBAC documentation describes system:masters as bound to cluster-admin, and kubeadm describes it as a break-glass group that bypasses authorisation. Plan a CA rotation now, even if it runs later in the day.
5. Restrict network reach while you rotate. Narrow the API server's authorised IP ranges or switch to a private endpoint where the platform supports it, so the leaked credential cannot be used from outside while rotation is prepared.
6. Rotate any cloud credentials found alongside. For exec plugin files, the cloud access key, refresh token or service account key is the real secret. See the Leaked Credential Response Playbook.

Managed cluster specifics

• Amazon EKS: aws eks update-kubeconfig writes an entry that authenticates with aws eks get-token, so access depends on the IAM principal. Review access entries (AWS describes them as the way to grant IAM principals Kubernetes permissions and to restore access through the EKS API) and any remaining aws-auth ConfigMap mappings. See the Amazon EKS Security Hardening Guide.
• Azure Kubernetes Service: Microsoft describes local accounts as enabled by default and the --admin credential as a non-auditable path. If an admin kubeconfig leaked, run az aks rotate-certs to rotate the cluster CA and refresh child certificates, then reissue user credentials with az aks get-credentials. Microsoft also advises rotating certificates after disabling local accounts on a cluster where people may have held local credentials. See the Azure Kubernetes Service Security Hardening Guide.
• Google Kubernetes Engine: Google's credential rotation replaces the control plane IP, cluster root CA, service account signing keys and aggregation layer CA. Old credentials are revoked at the complete step, and GKE completes a rotation automatically seven days after it starts. See the GKE Security Hardening Guide.

Eradication

Eradication means the leaked credential no longer works and nothing the attacker could have created survives.

• Self-managed CA rotation: The Kubernetes manual CA rotation task asks you to back up the certificate directory first, assumes a highly available control plane, and warns that a single API server will be unavailable while it restarts. The process distributes the new CA alongside the old, updates the certificate-authority-data in kubeconfig files, updates service account tokens and the cluster-info ConfigMap where bootstrap tokens are used, restarts components as a rolling update, and only then removes the old CA. Pods using an in-cluster kubeconfig need a restart to pick up the new data.
• Service account signing keys: Because TokenRequest tokens have no specific invalidation mechanism, a leaked token bound to a long-running workload is removed by deleting the Pod it is bound to (which expires its bound tokens), or by rotating the signing key set by --service-account-key-file when the scope is wide. See How to rotate a Kubernetes service account token and detect old token use.
• Persistence sweep: Look for objects created by the leaked identity during the exposure window: new ClusterRoleBindings, service accounts with token Secrets, CertificateSigningRequests approved for client authentication, mutating or validating webhooks, DaemonSets, privileged Pods, and changes to kube-system. Each one can outlive the credential that created it.
• Source removal: Remove the file from Git history, not just the latest commit, and rotate first: rewriting history does not reach clones and forks already made. See the Git Secret Scanning Guide.

Recovery

1. Reissue legitimate access with less privilege. kubeadm's documentation warns against sharing super-admin.conf or admin.conf and recommends least privileged credentials even for administrators, keeping the super-admin file for break-glass use only. Use this event to move people to identity provider sign-in with group-based RBAC.
2. Prefer short-lived credentials. Issue client certificates through the CertificateSigningRequest API with spec.expirationSeconds (honoured from Kubernetes v1.22) rather than year-long certificates, or use OIDC or cloud exec plugins.
3. Update every client. CI runners, GitOps controllers, monitoring agents and operators that hold kubeconfigs need the new CA data and new credentials. Inventory them before the old CA is removed, not after.
4. Restore network exposure only as needed. Keep authorised IP ranges or a private endpoint if the incident showed the public endpoint was not required.
5. Confirm the old credential fails. From an isolated test host, use a copy of the leaked kubeconfig against the API server and confirm an authentication failure. Record the result as evidence of closure.

Evidence to preserve

Collect these before rotation and before audit logs roll over. The Kubernetes audit documentation describes events generated at request stages, filtered by a policy and written to a log file or webhook backend, so confirm where your cluster's events go and how long they are kept.

Useful audit annotations include authorization.k8s.io/decision and, for legacy service account tokens, authentication.k8s.io/legacy-token-invalidated, which Kubernetes adds when an invalidated auto-generated token is used. See the Kubernetes Audit Log Detection Guide for query patterns.

Notification triggers

• Personal data: If the audit trail shows reads of Secrets, ConfigMaps or volumes holding personal data, or you cannot rule it out, GDPR Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals. Record the decision either way.
• Sector and national rules: Operators within NIS2 scope, DORA scope or US federal contracts have their own reporting clocks for significant incidents. Use the Cyber Incident Reporting Requirements Map to check which apply.
• Customers and partners: Multi-tenant platforms and managed service providers usually have contractual notice duties when a shared cluster credential leaks, even without evidence of use.
• Researcher reports: If an external researcher reported the leak, acknowledge receipt and confirm remediation in line with your disclosure policy.

Detection and measurement

• Alert on admin identities from new places: Requests from system:masters members, kubernetes-admin or break-glass users from source IPs outside your management ranges.
• Alert on credential minting: Creation of token Secrets, approved client-authentication CSRs, and new ClusterRoleBindings to cluster-admin.
• Scan for kubeconfig patterns: Secret scanners should flag files containing client-key-data, apiVersion: v1 with kind: Config, and bearer tokens in YAML.

Framework mapping

Practitioner checklist

• Classify every user entry in the leaked file as certificate, token or exec plugin before acting.
• Remove the exposed copy and assume it has already been copied.
• Delete RBAC bindings and cloud access mappings for the leaked identity within the first hour.
• Revoke Secret-based tokens, static tokens, bootstrap tokens and identity provider sessions where they apply.
• Plan a cluster CA rotation for any leaked privileged or long-lived client certificate, with all clients inventoried first.
• Restrict API server network exposure while rotation is prepared.
• Export audit events, cloud trail entries and RBAC snapshots before changing anything else.
• Sweep for persistence created during the exposure window: bindings, service accounts, CSRs, webhooks, DaemonSets.
• Reissue access through identity provider sign-in or short-lived certificates, and keep super-admin credentials offline.
• Record the notification decision and confirm the leaked credential now fails.

Standards and references

• Kubernetes: Authenticating
• Kubernetes: Organizing Cluster Access Using kubeconfig Files
• Kubernetes: Manual Rotation of CA Certificates
• Kubernetes: Managing Service Accounts
• Kubernetes: Certificate Management with kubeadm
• Kubernetes: Auditing
• Microsoft Learn: Certificate management and rotation in AKS
• Google Cloud: Rotate your cluster credentials (GKE)

Related NHI Mgmt Group resources: Kubernetes Cluster Compromise Playbook · Kubernetes RBAC Guide · Kubernetes NHI Security Guide · Leaked Credential Response Playbook