Agentes de IA¶

Un agente de IA como Claude Code o Cursor puede trabajar en tus clusters a través del servidor MCP de kubelatch. Se conecta a una dirección, lo autorizas en tu navegador y actúa como tú solo con los permisos que elijas, durante unas horas. kubelatch registra cada llamada que hace, puede retener sus cambios hasta que los apruebes y te deja cortarle el acceso en cualquier momento.

Por qué no darle tu kubeconfig¶

Eres developer en shop y le pides a tu agente «mira por qué falla el pod web». Sin kubelatch tienes dos opciones malas: le das tu kubeconfig, y puede todo lo que puedes tú mientras en la auditoría solo apareces tú; o pides un bot a un administrador y esperas, cosa que nadie hace para una tarea de diez minutos.

kubelatch añade una tercera: autorizas tú al agente. Es el gesto de «Iniciar sesión con Google»: no das tu contraseña, das un permiso limitado que puedes retirar.

Conecta tu agente¶

1. Una vez, añade kubelatch a tu agente. En «Inicio», «Conectar un agente» te da el comando con la dirección de tu kubelatch. Para Claude Code:

   claude mcp add --transport http kubelatch https://kubelatch.example.com/mcp
   

   Para Cursor, en .cursor/mcp.json:

   {
     "mcpServers": {
       "kubelatch": {
         "url": "https://kubelatch.example.com/mcp"
       }
     }
   }
   

   Cualquier otro cliente MCP: Streamable HTTP en esa dirección; inicia sesión con OAuth. Con Claude Code puedes instalar en su lugar el plugin, que añade el servidor y las reglas para el agente.

2. La primera vez que el agente usa kubelatch, se abre tu navegador en kubelatch, donde ya tienes sesión (si no, entras y te devuelve allí).

3. Ves «¿Dejar que Claude Code actúe como tú?» (con el nombre del agente), sobre «Quién pide»: el «Agente», el sitio al que «Vuelve a» el navegador al responder y cuánto dura la petición. Bajo «Qué recibe · hasta cuándo» están tus permisos, agrupados por cluster. Para cada uno, elige qué recibe el agente con los tres botones que lo acompañan: «No incluir», «Solo lectura (viewer)» o «Mismo rol (…)»; «Todo en solo lectura» y «Todo como yo (sin cluster-admin)» los ponen todos a la vez. Debajo, «Permisos que recibas más adelante» tiene los mismos tres botones («No incluir», «Solo lectura (viewer)» y «Mismo rol»), puesto en «Solo lectura (viewer)»; «Todo en solo lectura» y «Todo como yo (sin cluster-admin)» también lo ponen. Después, la «Duración» (8 h salvo que tus administradores la cambiaran) y si «Las escrituras piden mi aprobación» (activado). Una frase sobre los botones lo resume, por ejemplo «Claude Code actuará como tú con 2 permisos durante 8 h, y lo que recibas después, en solo lectura; cada escritura espera tu aprobación.». Pulsa «Autorizar».
4. El navegador te dice «Autorizado. Vuelve al agente.» y el agente sigue.

En esa página:

• «Solo lectura (viewer)» se ofrece, y viene elegido, solo para un permiso cuyo rol incluye viewer sin serlo: developer, admin y cluster-admin. Un permiso viewer viene como «Mismo rol (viewer)», ya elegido. Un permiso debugger, secrets-reader o de un rol personalizado solo se puede pasar tal cual, y viene en «No incluir»: elige «Mismo rol (…)» solo si el agente lo necesita. Tienes que incluir al menos un permiso.
• cluster-admin solo se puede pasar como «Solo lectura (viewer)»: un agente nunca hereda cluster-admin.
• Un nombre que el agente se da a sí mismo aparece marcado «sin verificar»: kubelatch no lo ha comprobado. Un agente que publica su identidad muestra «publicado por …», con el sitio que lo publica.
• La línea justo encima de los botones dice adónde va tu respuesta. Para un agente que solo vuelve a tu propio ordenador es «Este agente se ejecuta en tu ordenador. Autorízalo solo si acabas de conectarlo tú.»; para uno que tiene otras direcciones pero esta vez vuelve a este ordenador, «Este agente recibe tu respuesta en …, en este ordenador. Autorízalo solo si acabas de conectarlo tú.» Las dos son recordatorios discretos. Cualquier respuesta que vaya a otro sitio levanta un aviso destacado: «Este agente recibe tu respuesta en …, fuera de este ordenador. Autorízalo solo si conoces esa dirección y acabas de conectarlo tú.» o, si va a una aplicación que abre sus propios enlaces (como cursor://), «Este agente recibe tu respuesta a través de la aplicación que abra los enlaces … en este ordenador, sea cual sea, y esa aplicación puede reenviarla. Autorízalo solo si acabas de conectarlo tú desde esa aplicación.» Si no acabas de conectar ninguno, pulsa «Denegar». Qué direcciones puede usar un agente está en Inicio de sesión de agentes delegados.
• Si se acaba el tiempo antes de que respondas, los botones dan paso a «Esta petición ya no vale: vuelve al agente y conéctalo de nuevo.»
• Un permiso que tienes por dos vías, directo y a través de un grupo, es una sola fila, marcada «vía grupo …» cuando lo da un grupo, como en «Mi acceso». Tu elección vale para todas las vías que hay detrás de la fila.
• «Permisos que recibas más adelante» es lo que pasa cuando recibes un permiso después de autorizar al agente, directo, en lote o por entrar en un grupo. «Solo lectura (viewer)» da al agente viewer allí, «Mismo rol» el mismo rol y «No incluir» nada. El agente lo tiene desde su siguiente llamada, sin conectarlo de nuevo, y lo pierde cuando termina la sesión o tu permiso. «Solo lectura» vale únicamente para un rol que incluye viewer; un permiso debugger, secrets-reader o de un rol personalizado que recibas después solo pasa con «Mismo rol»; y cluster-admin nunca pasa como tal, sino como viewer. La página de la sesión muestra tu elección como «Permisos posteriores».

Qué ve y qué hace el agente¶

• Los clusters te ven a ti, user:<tu login>, pero solo con los permisos que diste al agente. Lo que su rol no permite, el cluster lo rechaza con un 403, aunque tú sí podrías.
• Tiene herramientas para leer (listar objetos, leer uno, logs, eventos, valores de Secrets), para cambiar (aplicar un objeto, borrar uno, escalar, reiniciar un rollout) y para pedir más acceso. Servidor MCP las enumera. Todos los agentes ven las herramientas que cambian cosas, sea cual sea su rol: un cambio que su rol no permite recibe el 403 del cluster, y puede pedirte más con request_access (mira más abajo).
• Los valores de los Secrets quedan ocultos salvo que el agente los pida a propósito, y cada una de esas lecturas queda registrada.
• Pídele que llame a whoami para ver qué puede hacer, dónde y hasta cuándo.
• Lo que hizo lo ves en «Agentes»: cada sesión tiene una línea de tiempo con cada llamada. Si un administrador mira la auditoría, las peticiones de tu agente aparecen como tuyas, a través del agente.

Qué te pedirá aprobar¶

Cuando incluyes un rol que escribe, como «Mismo rol (developer)», y dejas «Las escrituras piden mi aprobación» activado, cada cambio que quiera el agente te espera, y lo ves antes de que ocurra:

1. El agente te da un enlace, https://kubelatch.example.com/agents/requests/…. «Agentes» en la barra lateral muestra cuántas solicitudes te esperan, y la campana también, que abre la solicitud misma cuando solo espera una.
2. La página se titula con el cambio en una frase (por ejemplo «deploy-bot quiere cambiar configmaps/feature-flags en apps (kind-local)») y dice quién la pidió y cuánto queda. Una línea resume lo que hace el cambio («Cambia 2 líneas de data»), y «Cambios» enseña el objeto actual frente a lo que el cluster dice que será, con − las líneas que se van y con + las que llegan. Los metadatos que gestiona el servidor vienen plegados. Los valores de los Secrets siguen ocultos, y uno que la escritura cambia se lee <redacted, N bytes, changed>.
3. Pulsa «Aprobar» o «Denegar»; en el móvil, los dos botones se quedan al pie de la pantalla. Cada uno te pide confirmar con la frase del cambio. Una vez aprobada, la escritura se ejecuta una vez, tal como la viste. La página dice entonces qué fue de ella: «Aprobada por alex a las 17:21 · se ejecutó una vez, el cluster respondió 201.»

Muchas veces no tienes que llevar el enlace. Un cliente que sabe preguntar, como Claude Code (su runtime por defecto desde la 2.1.274, sin plugin), te enseña el cambio en una frase y te pide abrir la página de la solicitud en el navegador. Acepta, decide allí, y la llamada del agente sigue sola y devuelve el resultado, cuya primera línea dice «approved by alex at …». La llamada espera tu decisión cerca de un minuto y después vuelve a preguntar; la solicitud sigue abierta. Si rechazas la pregunta, o el agente se ejecuta sin pantalla (claude -p), o su cliente no sabe preguntar, el agente te da el enlace en texto y vuelve a llamar con el approval_id cuando hayas decidido; esa llamada también te espera.

En «Agentes», una solicitud pendiente tiene además «Aprobar» en su fila. Pide la misma confirmación que la página, con la frase, lo que hace el cambio y el tiempo que queda, así que puedes aprobarla sin abrir la página. Ábrela para leer antes el diff entero.

Una escritura te espera 15 minutos; una vez aprobada, el agente tiene 15 minutos para ejecutarla.

Para una tarea con varios cambios, el agente puede pedir en su lugar un rol durante un tiempo, por ejemplo developer en shop durante 30 minutos. Lo apruebas en el mismo tipo de página; mientras dura, las escrituras del agente allí no te preguntan una a una. Solo puede pedir un rol que tengas en ese cluster y namespace, nunca cluster-admin, durante 8 horas como mucho.

Cuánto molesta: el navegador se abre una vez por sesión, como kubelatch login. En solo lectura no hay ninguna confirmación.

Córtale el acceso¶

La sesión termina sola cuando se acaba su duración. Antes, en «Agentes», abre la sesión y pulsa «Cortar»: se revocan sus tokens, se cierran sus solicitudes pendientes y terminan los permisos que le diste. Su siguiente llamada falla. Conectarlo de nuevo te lo vuelve a preguntar.

Si revocan o caduca un permiso tuyo, el agente pierde al momento lo que venía de él.

Los agentes de tu equipo¶

Un agente que no es tuyo, como uno de guardia que revisa alertas por la noche, usa un bot que crea un administrador, con los permisos que el administrador le concede (Agentes de IA para administradores). Ese agente y el tuyo no se tocan: tu Claude Code actuando como tú en solo lectura y bot:ops-agent, viewer en todos los namespaces, son dos identidades.

El plugin de Claude Code¶

El plugin kubelatch añade kubelatch a Claude Code junto con las reglas que hacen que lo use:

claude plugin marketplace add picaportelabs/kubelatch
claude plugin install kubelatch@kubelatch

Al activar el plugin, Claude Code te pide kubelatch URL: la dirección de tu kubelatch, como https://kubelatch.example.com, sin /mcp. Puedes cambiarla después en /config. Después, el agente inicia sesión como en Conecta tu agente. No añadas además el servidor con claude mcp add: el agente lo vería dos veces.

El plugin trae:

• el servidor MCP de kubelatch;
• la skill kubernetes-via-kubelatch: usa las herramientas de kubelatch para todo lo de Kubernetes, empieza por whoami, un 403 es una respuesta, y cómo van las aprobaciones;
• un hook que rechaza las órdenes de kubectl, helm y k9s que llegan a un cluster, y kustomize build | kubectl, y le dice al agente qué herramienta usar en su lugar. Las órdenes que no llegan a un cluster, como helm template, kustomize build o kubectl kustomize, siguen funcionando.

Para otros agentes, las mismas reglas están en integrations/rules/: pega kubernetes-via-kubelatch.md en el AGENTS.md de tu proyecto (Claude Code solo lee AGENTS.md cuando no hay CLAUDE.md; si lo hay, pégalo en CLAUDE.md), o copia kubelatch.mdc a .cursor/rules/ para Cursor.