// use cases

One tool, four kinds of access.

The same broker serves the people who run the clusters, the people who deploy to them, the pipelines and the AI agents. Each gets a credential of its own, with an owner, an expiry and a record; the admin kubeconfig goes back in the vault, for emergencies.

// owner, expiry, record

Platform teams

You run the clusters, so the questions land on you: who can reach prod-eu, with what, until when, and who touched it last night. With kubelatch each answer is a page you open, not an afternoon of digging.

• Permissions lists who holds which role on which cluster and namespace, and until when. What expires within a week turns amber; under 24 hours, red.
• Revoke a credential and its next request gets a 401, with no grace window; an open exec or watch is cut within 10 seconds. Revoke a permission and its binding leaves the cluster within seconds.
• Permissions by role: six fixed system roles, from viewer to cluster-admin, over a namespace or the whole cluster. kubelatch creates the bindings on each cluster and deletes them when nobody needs them, so nobody writes one by hand. The namespace stays the boundary: whoever can create pods in one reaches its Secrets.
• The audit keeps every request through the proxy: who, where, what and the result, with the command of each exec. A search lives in its URL, so a link reproduces it, and the API exports the rows when an auditor asks. Free shows the last 24 hours; Pro keeps them as long as you configure.

The step: install kubelatch, one Helm chart on a management cluster, with your own Postgres or one the chart creates.

// a kubeconfig of your own

Developers

You want to deploy to shop, read a log, open a shell in a pod, and get back to your work. With kubelatch you do it with a credential that's yours and the tools you already use.

• Once an administrator grants you a permission (you can't grant one to yourself), you issue a credential on Home: a name, 1, 7 or 30 days, and a kubeconfig with a context for each cluster you can reach. From a terminal, kubelatch login signs you in through the browser and keeps it for you.
• kubectl, k9s, Lens and Helm work unchanged, exec, logs -f and port-forward included, and kubectl auth whoami shows you as user:<your login>. What doesn't work is kubectl --as.
• My activity lists the requests your credentials made, the command of each exec included, with the Audit-ID to paste to an administrator.
• Every credential expires, in 30 days at most by default, and you revoke yours from Home. The token on a laptop lost next year opens nothing: it expired long before.

The step: try it locally, with a disposable kind cluster, in about 15 minutes plus the first downloads. If your team already runs kubelatch, sign in and ask for access.

// no secret in GitHub

CI pipelines

A deploy job has to reach the cluster, and the quick way is a kubeconfig pasted into the repository's secrets: shared by every workflow, rotated by nobody. kubelatch gives each run a credential of its own instead, and keeps nothing in GitHub.

• A GitHub Actions workflow asks GitHub for the OIDC token it signs for that run, and exchanges it at kubelatch for a credential and its kubeconfig. There's no secret to store, and none to rotate.
• That credential lasts 1 hour by default, enough for a job; an administrator can change it. Each OIDC token can be exchanged only once, so one captured after the job used it is worthless.
• A trust rule ties a repository, by its numeric ids, to a bot, and optionally to one branch or one environment. Every kubectl of the job is in the audit as that bot, and the credential's note carries the repository, the ref, the run and who triggered it.
• Other CI systems, and tools like Argo CD, use a bot's credential issued by hand: it expires in 90 days at most and lives in that tool's secret store. The exchange is for GitHub Actions only, on github.com or GitHub Enterprise Server.

The step: create the trust rule, and kubelatch hands you the workflow, filled in with your address. The runners must reach kubelatch over https, so a kubelatch on a laptop won't do.

// Kubernetes in the age of AI

AI agents

You'd like your coding agent to find out why the web pod is failing, without handing it your kubeconfig, and without waiting for an administrator to make it a bot.

• It works as you, with only the permissions you choose when you authorize it in the browser: read-only by default, for a few hours (8 by default).
• With “Writes need my approval” on, as it comes, every change it wants waits for you with the diff, and runs once when you approve it.
• Every request it sends to a cluster is in the audit as you, through the agent, and Cut ends the session before its time.
• No kubectl and no kubeconfig on the developer's machine: the agent works through kubelatch's MCP server. It does what its tools do; for an exec, a port-forward or a logs -f, a person still uses kubectl.

The step: read how it works, then connect yours.