// casos de uso

Una herramienta, cuatro tipos de acceso.

El mismo broker sirve a quien gestiona los clusters, a quien despliega en ellos, a los pipelines y a los agentes de IA. Cada uno tiene su propia credencial, con dueño, caducidad y registro; el kubeconfig de admin vuelve a la caja fuerte, para emergencias.

// dueño, caducidad, registro

Equipos de plataforma

Tú gestionas los clusters, así que las preguntas te llegan a ti: quién entra en prod-eu, con qué, hasta cuándo, y quién tocó algo anoche. Con kubelatch cada respuesta es una página que abres, no una tarde rebuscando.

• «Permisos» muestra quién tiene qué rol en qué cluster y namespace, y hasta cuándo. Lo que caduca en menos de una semana se pone ámbar; en menos de 24 horas, rojo.
• Revoca una credencial y su siguiente petición recibe un 401, sin periodo de gracia; un exec o un watch abiertos se cortan en menos de 10 segundos. Revoca un permiso y su binding desaparece del cluster en segundos.
• Permisos por rol: seis roles de sistema fijos, de viewer a cluster-admin, sobre un namespace o el cluster entero. kubelatch crea los bindings en cada cluster y los borra cuando ya nadie los necesita, así que nadie escribe uno a mano. El namespace sigue siendo la frontera: quien puede crear pods en uno llega a sus Secrets.
• La auditoría guarda cada petición que pasa por el proxy: quién, dónde, qué y con qué resultado, con el comando de cada exec. Una búsqueda vive en su URL, así que un enlace la reproduce, y la API exporta las filas cuando te las pide un auditor. Free muestra las últimas 24 horas; Pro las guarda el tiempo que configures.

El paso: instala kubelatch, un chart de Helm en un cluster de gestión, con tu propio Postgres o con uno que crea el chart.

// un kubeconfig propio

Desarrolladores

Quieres desplegar en shop, leer un log, abrir una shell en un pod y volver a lo tuyo. Con kubelatch lo haces con una credencial que es tuya y con las herramientas que ya usas.

• En cuanto un administrador te concede un permiso (tú no puedes dártelo), emites una credencial en «Inicio»: un nombre, 1, 7 o 30 días, y un kubeconfig con un contexto por cada cluster al que llegas. Desde la terminal, kubelatch login abre el navegador para que entres y guarda la credencial por ti.
• kubectl, k9s, Lens y Helm funcionan tal cual, con exec, logs -f y port-forward, y kubectl auth whoami te muestra como user:<tu login>. Lo que no funciona es kubectl --as.
• «Mi actividad» lista las peticiones que han hecho tus credenciales, con el comando de cada exec, y el Audit-ID para pasárselo a un administrador.
• Toda credencial caduca, como mucho a los 30 días por defecto, y la tuya la revocas tú desde «Inicio». El token de un portátil que pierdas el año que viene no abre nada: caducó mucho antes.

El paso: pruébalo en local, con un cluster kind desechable, en unos 15 minutos más las primeras descargas. Si tu equipo ya usa kubelatch, entra y pide acceso.

// sin secretos en GitHub

Pipelines de CI

Un job de despliegue tiene que llegar al cluster, y lo rápido es pegar un kubeconfig en los secretos del repositorio: lo comparten todos los workflows y no lo rota nadie. kubelatch da a cada ejecución su propia credencial y no guarda nada en GitHub.

• Un workflow de GitHub Actions pide a GitHub el token OIDC que firma para esa ejecución y lo canjea en kubelatch por una credencial con su kubeconfig. No hay secreto que guardar, ni que rotar.
• Esa credencial dura 1 hora por defecto, suficiente para un job; un administrador puede cambiarlo. Cada token OIDC se canjea una sola vez, así que uno capturado después de que lo use el job ya no sirve.
• Una regla de confianza une un repositorio, por sus ids numéricos, con un bot, y si quieres con una sola rama o un solo entorno. Cada kubectl del job queda en la auditoría como ese bot, y la nota de la credencial lleva el repositorio, la ref, la ejecución y quién la lanzó.
• Otros sistemas de CI, y herramientas como Argo CD, usan una credencial de bot emitida a mano: caduca a los 90 días como mucho y vive en el gestor de secretos de esa herramienta. El canje es solo para GitHub Actions, en github.com o en GitHub Enterprise Server.

El paso: crea la regla de confianza, y kubelatch te da el workflow ya rellenado con tu dirección. Los runners tienen que llegar a kubelatch por https, así que un kubelatch en un portátil no sirve.

// Kubernetes en la era de la IA

Agentes de IA

Quieres que tu agente de programación averigüe por qué falla el pod web, sin darle tu kubeconfig y sin esperar a que un administrador le cree un bot.

• Trabaja como tú, solo con los permisos que eliges al autorizarlo en el navegador: en solo lectura por defecto, durante unas horas (8 por defecto).
• Con «Las escrituras piden mi aprobación» activado, como viene, cada cambio que quiera te espera con su diff, y se ejecuta una vez cuando lo apruebas.
• Cada petición que manda a un cluster queda en la auditoría a tu nombre, a través del agente, y Cortar termina la sesión antes de tiempo.
• Ni kubectl ni kubeconfig en la máquina del desarrollador: el agente trabaja a través del servidor MCP de kubelatch. Hace lo que permiten sus herramientas; para un exec, un port-forward o un logs -f, una persona sigue usando kubectl.

El paso: lee cómo funciona y conecta el tuyo.