KubeDriveDownloadDownloadDownload
Blog

Give your AI agent a cluster, not a kubeconfig

Ask Claude Code why a deployment is not ready and it does the right things: reads the events, checks the pods, pulls a log, finds the missing ConfigMap. To do that it needs to reach the cluster, and the usual way is kubectl in its shell with your kubeconfig. That file is your identity. On a production cluster it is often an SSO session, a cloud role, or a token that can delete namespaces. The agent now has all of it, in a process that also runs arbitrary commands and talks to a model provider.

Most people solve this by not doing it on production. We wanted a way to do it.

The agent asks, KubeDrive answers

KubeDrive already holds your connections: the kubeconfig, the SSO sessions it refreshed, the permissions RBAC gives you. So instead of copying those into the agent, KubeDrive serves them. It runs a small Model Context Protocol server on your computer, and the agent calls it the way it calls any tool: list_resources in a namespace, get_logs of a container, diagnose an object. KubeDrive makes the request to the API server with your credentials and returns the answer.

The agent never sees a kubeconfig, a token or an API server address. What it holds is one bearer token for KubeDrive itself, on 127.0.0.1, which opens nothing but the clusters you ticked. New Token in the AI Agents window turns every agent away at once; Turn Off stops the server. Your credentials stay where they were, and so do your permissions: the agent can read what you can read, and check_access tells it so before it tries.

A shared cluster is remembered together with the API server it pointed at. If your kubeconfig later points that context name at a different cluster, the agent is refused until you share it again. A name is not a cluster.

Credentials stay inside

Reading is the easy half. The hard half is that a cluster is full of secrets that are not in Secrets: a database password in a container’s environment, a token in a ConfigMap, a bearer header in a log line, the whole object again in kubectl’s last-applied-configuration annotation. Whatever the agent reads goes to its model provider, as with anything else you show it.

So KubeDrive redacts before the agent sees anything:

  • a Secret keeps its keys, each value replaced by its size, so the agent can still tell you that tls.key is empty;
  • environment variables and map keys named like PASSWORD, TOKEN, API_KEY or CREDENTIAL lose their values, in ConfigMaps and custom resources too, while references such as secretName are kept because they help;
  • every other string, in objects and in logs, is masked like log text: passwords in URLs, bearer tokens, JWTs, cloud keys, private keys.

This is a heuristic, and we say so in the docs: keep credentials in Secrets. But it means the ordinary case, an agent reading a pod spec with DATABASE_URL in it, does not leak the password.

Changes wait for you

With reading only, there is nothing to misuse: the server has no tool to apply, scale, delete or exec. We added those as a separate switch, and they work differently from reads.

An agent that calls apply gets a server-side dry run first. Then a window opens in KubeDrive with the cluster, the object and the diff, and the agent waits up to two minutes for your Allow. Deny, or no answer, comes back to it as an error and nothing changed. The same window shows the command of an exec and the target of a delete. On a cluster you marked protected, you type the object’s name before the change goes through, as for KubeDrive’s own buttons. And the change itself runs through the same code those buttons use, with your credentials.

One detail took some care. A diff masks credentials, so an agent could, in principle, change a password behind a line that reads <redacted> on both sides. A hidden value that changes is marked (changed) in the diff, so the one thing the mask would hide is the one thing it points at.

The window keeps a journal of the last fifty changes agents asked for: tool, object, allowed or not. Arguments and outputs are not stored.

What it is like

Turn it on with ⌘K → AI Agents…, tick a cluster, copy the one-line command into Claude Code or the entry into Codex’s config, and ask. The robot icon in the title bar lights at each call, so you can see the agent at work rather than take its word for it.

Reading is free. Changes by agents are part of KubeDrive Pro. The setup for Claude Code, Codex, Claude Desktop and Cursor is in the AI agents guide, and the tool list is there too: thirteen read tools, from get_events to upgrade_check, and twelve that change things, each behind your Allow.