Un agente de IA en tu cluster, sin tu kubeconfig

Para averiguar por qué falla un pod, tu agente tiene que llegar al cluster, y las maneras habituales de darle acceso son malas. Con kubelatch entra como tú, con menos permisos de los que tienes, durante unas horas y con sus cambios esperando tu visto bueno. También cuento dónde se queda corto.

Dos opciones malas

Eres developer en shop y le pides a tu agente «mira por qué falla el pod web». Sin kubelatch tienes dos opciones.

La primera es darle tu kubeconfig. Es inmediato, y el agente puede hacer lo mismo que tú mientras dure tu credencial. Eso sí, en la auditoría solo apareces tú, así que luego no se distingue lo que hiciste tú de lo que hizo él.

La segunda es pedirle a un administrador que te cree un bot: él decide qué puede hacer y le da una credencial de hasta 90 días. Para un agente de todo el equipo tiene sentido; para una tarea de diez minutos en tu portátil, no compensa.

Un agente delegado trabaja como tú, dentro de tus límites

kubelatch añade una tercera vía, que funciona como «Iniciar sesión con Google»: en lugar de dar tu contraseña, das un permiso limitado que puedes retirar.

Añades el servidor MCP de kubelatch a tu agente una sola vez. Todos los clientes MCP, Cursor incluido, se conectan a la misma dirección; en Claude Code basta esta línea:

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

La primera vez autenticas el servidor MCP de kubelatch en tu cliente (en Claude Code, desde /mcp) y el navegador se abre solo en kubelatch (si no tenías la sesión iniciada, entras y vuelves ahí) con la pregunta «¿Dejar que Claude Code actúe como tú?». Para cada permiso tuyo eliges qué le pasas al agente: nada, solo lectura (viewer) o el mismo rol. De entrada viene en solo lectura, y un agente nunca hereda cluster-admin. Debajo eliges la duración, que de entrada es de 8 horas salvo que tus administradores la hayan cambiado, y tienes el interruptor «Las escrituras piden mi aprobación», que viene activado.

A partir de ahí, el cluster te ve a ti, user:<tu login>, pero solo con los permisos que le has dado al agente. Lo que su rol no permite, el cluster lo rechaza con un 403, aunque tú sí puedas hacerlo. En la auditoría, sus peticiones salen como tuyas, hechas a través del agente. Si necesita más, lo pide con request_access y decides tú (el techo de un agente delegado).

Las escrituras te esperan

Si le pasas al agente tu rol developer, o cualquier otro que pueda escribir, y dejas activado «Las escrituras piden mi aprobación», cada cambio que quiera hacer espera a que decidas. Primero, kubelatch lo prueba en el cluster con un dry run; si el cluster lo rechaza, el agente recibe esa respuesta y no queda nada pendiente.

Si pasa el dry run, el cambio se queda esperando en una página que lo resume en una frase. Ahí ves el objeto como está ahora y cómo quedará según el cluster, con los valores de los Secrets ocultos. Pulsas «Aprobar» o «Denegar» y confirmas. Si lo apruebas, la escritura se ejecuta una sola vez y tal como la has visto. Claude Code te ofrece abrir esa página; otros clientes te pasan el enlace. Cada escritura te espera 15 minutos.

Para una tarea con varios cambios, el agente puede pedirte un rol temporal, por ejemplo developer en shop durante 30 minutos. Lo apruebas una vez y, mientras dure, ya no te pregunta por cada escritura en shop. Solo puede pedirte un rol que tengas tú, nunca cluster-admin, y como mucho durante 8 horas. Si solo lee, no te pide nada (qué te pedirá aprobar).

El corte

Una sesión delegada termina sola cuando se le acaba el tiempo. Si no quieres esperar, ábrela en «Agentes» y pulsa «Cortar»: se revocan sus tokens, se cierran sus solicitudes pendientes y terminan los permisos que le has dado. Su siguiente llamada falla, y para volver a conectarlo tendrás que autorizarlo otra vez.

Hay cortes que no dependen de ti. Si te quitan un permiso o se te caduca, el agente pierde al momento lo que tenía por ese permiso: su acceso nunca dura más que el tuyo. En «Agentes» ves cada sesión: en nombre de quién actúa, con qué permisos y hasta cuándo (córtale el acceso).

Ni kubectl ni kubeconfig en el portátil

Para mí, Kubernetes en la era de la IA es esto: el agente habla con kubelatch por MCP, tú lo autorizas en el navegador una vez por sesión y, para el trabajo que hace, no hay ni kubectl ni kubeconfig en tu máquina. Tu kubeconfig ni siquiera le serviría ahí: el endpoint MCP de kubelatch no acepta credenciales de personas. Si usas Claude Code, el plugin de kubelatch trae un hook que rechaza los comandos de kubectl, helm y k9s que van contra un cluster y le dice al agente qué herramienta usar en su lugar.

La pega es que el agente solo puede hacer lo que ofrecen las herramientas MCP (listar, leer, describir, logs, eventos, estado de un rollout, uso de CPU y memoria, aplicar, borrar, escalar, reiniciar un rollout, leer un Secret, pedir acceso): no hay exec, port-forward, watch ni logs -f, y para eso sigue haciendo falta una persona con kubectl y su propia credencial.

Lo que esto no resuelve

kubelatch solo acota lo que el agente hace a través de él:

• Lo que lee le puede dar órdenes. Los logs y los campos de los objetos pueden traer texto escrito a propósito para manipular a un modelo. kubelatch no lo filtra; el daño lo limitan el techo y las aprobaciones.
• Oculto no quiere decir prohibido. Los valores de los Secrets llegan ocultos en lo que el agente lista y lee, pero read_secret se los devuelve a cualquier agente cuyo rol pueda leer Secrets, y cada lectura queda registrada. Un Secret solo sigue siendo secreto si el rol del agente no puede leerlo, como pasa con viewer. Lo que el agente ya ha leído se queda en su contexto y en el historial del proveedor del modelo, aunque cortes la sesión. Los ConfigMaps y los logs no se ocultan nunca.
• Las aprobaciones dan por hecho que quien pulsa es una persona. Un agente que controle tu navegador podría aprobar sus propias solicitudes.
• Otras vías de entrada. Si el agente encuentra en tu máquina otro camino hacia un cluster (un kubeconfig, una sesión de kubelatch login, la CLI de una nube), puede usarlo sin que kubelatch se entere. El hook frena a un agente bienintencionado, pero se puede esquivar y solo funciona en Claude Code. Para trabajar así no te hace falta ningún kubeconfig: deja los que tengas fuera de su alcance.

Tienes la lista en la documentación: lo que no cubre y el modelo de seguridad.

Pruébalo

Con el tutorial en local montas kubelatch y un cluster desechable en tu máquina en unos 15 minutos. Su paso 14, opcional, te lleva otros cinco: conectas Claude Code para que actúe como tú y ves cómo un borrado espera tu aprobación. Free incluye agentes de IA sin límite, en 2 clusters y para 5 personas (precios). Detrás de kubelatch hay un estudio pequeño en España, de una sola persona; si algo de lo que cuento no cuadra con lo que ves, escríbeme.