// questions
What people ask first.
Short answers, limits included. Everything else is in the documentation.
My cluster already has SSO.
kubelatch doesn’t replace it and doesn’t stack another one on top: it registers as one more application with the provider your EKS, AKS or GKE already signs you in with, like Argo CD or Grafana, and you sign in with the session you already have open. On EKS with IAM Identity Center, kubelatch registers with the provider behind it (Okta, Entra ID, Google Workspace): Identity Center’s own directory offers applications SAML only, which kubelatch doesn’t support, so there people sign in with GitHub or local accounts. kubelatch adds what your SSO doesn’t have: permissions that expire on their own, an inventory of who holds what and until when, a readable row per request, and the same door for several clouds, for CI and for agents. The limit: the bindings your cluster already gives your SSO’s groups stay the cluster’s business; a kubelatch permission that puts you, for a while, in a group those bindings name comes in phase 1 · Free. And when someone leaves, your provider doesn’t tell kubelatch: you disable their account in Users, and until you do, what they hold keeps working until it expires.
We don’t share kubeconfigs.
Then you most likely sign in with your SSO already, and kubelatch starts there: permissions with an end date, a readable row per request, and the same door for every cloud, for CI and for agents. If an admin kubeconfig still goes around on some cluster, this comparison shows what changes.
Why not Teleport?
Teleport does more: SSH, databases, session recording. Its Community edition is only for companies under 100 employees and $10M in revenue, and OIDC sign-in is Enterprise only, priced through sales. kubelatch does Kubernetes only: one Go binary and a Postgres, nothing running inside the cluster, OIDC in Free and a public price of $15 per person per month, billed yearly, from 5 people. If you need servers and databases behind the same door, or a recording today of what an exec showed on screen, Teleport is the better choice, and the comparison says so. A record of what happens inside a session is on kubelatch’s roadmap, in phase 5 · Pro.
Is this only for teams using AI agents?
No. The agent is where the idea shows most clearly: it needs a ceiling, a deadline and a record of everything it does. Expiry, the audit and revocation work the same for a person and a pipeline, and a team with no agents uses all of that without touching the MCP server.
What about DORA, NIS2 and ENS?
No tool complies with a regulation for you, but kubelatch writes down part of what those rules ask of privileged access: an identifiable user on every request, permissions with a date, named emergency accounts and a record that never leaves your infrastructure (24 hours in Free; in Pro, what you configure). What isn’t there yet, and is planned for Pro in phase 3, is the evidence the auditor asks for: the export, the periodic reviews and the report.
Is it zero trust?
Partly. The core of it, yes: every request through kubelatch is checked against a credential that expires, with no cache in between; cluster-admin never lasts past 8 hours; and the Permissions screen counts the ones with no expiry so you can bring them to zero. What it doesn’t have yet is the rest of NIST’s definition: a decision that weighs the device, and a dynamic policy.