Someone left the team. They had admin kubeconfig access to production clusters. I needed to revoke their access immediately. Then I discovered: Kubernetes has no certificate revocation mechanism.
The Problem
Kubernetes client certificate authentication is one-way trust. The API server trusts any certificate signed by the cluster CA. There’s no CRL (Certificate Revocation List). There’s no OCSP responder. Once a kubeconfig with a valid client cert is issued, it works until the cert expires.
You can’t revoke it. You can only replace everything else.
The Procedure
The only way to invalidate an existing admin kubeconfig is to generate a new one and rotate all control plane components to use it. Here’s what that looks like on bare-metal clusters:
1. Generate a new admin certificate:
kubeadm kubeconfig user --client-name=backup-admin --org=system:masters
2. Replace admin.conf on every control plane node:
scp backup-admin.conf cp-node:/etc/kubernetes/admin.conf
3. Restart all control plane components — in order:
- API server
- Controller manager
- Scheduler
- etcd (if using client cert auth)
4. Restart the CNI (Cilium/Calico) on all nodes — it caches the old admin cert.
5. Restart kubelets on all nodes — they re-establish connections with the new API server certs.
6. Approve pending CSRs — kubelet restarts generate new CSRs that need approval:
kubectl get csr | grep Pending | awk '{print $1}' | xargs kubectl certificate approve
7. Validate — wait for all nodes to report Ready, check that all system pods are running.
16 steps total across every control plane node. One wrong step and the cluster is unreachable.
Why This Is Scary
On managed Kubernetes (GKE, EKS, AKS), this is handled for you — access is tied to IAM, not client certs. But on bare-metal or self-managed clusters (KubeOne, kubeadm, Rancher), admin kubeconfigs are just x509 certificates. There’s no “disable user” button.
If someone leaves with a copy of the kubeconfig, they have access until you rotate the entire control plane. And most teams never practice this procedure until they need it.
Takeaway
If you run self-managed Kubernetes clusters, script your kubeconfig rotation procedure before you need it. Test it on a non-production cluster. The day you need to revoke access is not the day to figure out the 16-step process. And consider moving to OIDC-based auth (Dex, Keycloak) where you can revoke tokens without touching the control plane.