// compare
kubelatch against the shared kubeconfig.
Many teams start with one admin kubeconfig that gets passed around, then a ServiceAccount made by hand for each person once the team grows. Both work on day one; this page shows what each leaves open, question by question, next to what kubelatch does.
// eight questions
Side by side.
| Question | Shared admin kubeconfig | Hand-made ServiceAccounts | kubelatch |
|---|---|---|---|
| Who holds it | Whoever got a copy: from a chat, a laptop, a CI secret. Nobody keeps the list. | One per person, as long as someone remembers to create it, and to delete it. | Every credential has an owner and a name, listed with what it reaches, when it expires and when it was last used. |
| Expiry | As long as the certificate or token inside it: often a year or more. | Whatever was set when the token was made; a long-lived token never expires. | Always. By default, 30 days at most for a person, 90 for a bot and 1 hour for a CI job. |
| What the API server sees | One identity, the same for everyone who holds it. | system:serviceaccount:…, one per person, named by convention. | The real person, user:ana, with only the groups of their active permissions. The cluster's native audit log records them as the impersonated user. |
| Revocation | Kubernetes can't revoke a client certificate: you rotate credentials on the whole cluster, or wait for it to expire. | Delete each token or ServiceAccount by hand, if you know which one. | Revoke it and its next request gets a 401; an open exec or watch is cut within 10 seconds. |
| Audit | The cluster's native audit log, if it's on, with one name for everyone. | Each cluster's native audit log, if it's on: one format and one place per provider. | Every request, recorded before it reaches the cluster, the same on every cluster, with an Audit-ID the native log shares. Free shows the last 24 hours. |
| CI pipelines | A copy of the kubeconfig in the CI's secrets. | A ServiceAccount token in the CI's secrets. | GitHub Actions exchanges its OIDC token for a credential that lasts 1 hour by default, and nothing is stored in GitHub. Other CI systems use a bot's credential, 90 days at most. |
| AI agents | The agent gets the kubeconfig, and everything it allows. | Someone's token ends up in the agent, and the audit can't tell the agent from that someone. | Through the MCP server, as you, with the permissions you pick, read-only by default; its writes can wait for your approval. |
| Setup cost | None: it already exists. | A ServiceAccount, a binding and a token per person, on every cluster. | A Helm chart and a Postgres on a management cluster, then one enrollment command per cluster. |
Each kubelatch cell comes from the documentation: identity, credentials, expiry and revocation, audit, CI, AI agents and install.
// the honest case
When the shared kubeconfig is fine.
One person, one disposable cluster, nothing to prove to anyone: a kind cluster on your laptop, a lab you delete on Friday. kubelatch is one more service and a database to run; for that case it's more than you need, and we'd rather tell you so.
- As a proxy, it sits on the path of every request: if kubelatch is down, people and CI lose access through it, though workloads keep running.
- It needs a management cluster with Kubernetes 1.30 or later, and a Postgres.
- It doesn't replace each cluster's own emergency access, which you keep, and test.
// the step
Try it on a cluster you can throw away.
The local tutorial runs kubelatch on your machine with a disposable kind cluster: you grant yourself a permission, use kubectl through it, read the audit and revoke the credential. About 15 minutes, plus the first downloads.