Por qué existe kubelatch

Al principio, casi todos los equipos entran en sus clusters de Kubernetes de la misma forma: con un kubeconfig de administrador para todos. Nadie se para a decidirlo: es lo que trae el cluster el primer día, y funciona. kubelatch existe porque ese fichero sale cada vez más caro sin hacer ruido, y porque la alternativa no tiene por qué ser un proyecto grande.

El fichero que tiene todo el mundo

Al crear un cluster te dan un kubeconfig que lo puede todo. Alguien lo guarda en un sitio seguro, muchas veces en un gestor de contraseñas. Luego el primero que tiene que mirar un pod se lo copia en el portátil. Llega alguien nuevo al equipo y se lo copia en el suyo. El pipeline de despliegue necesita entrar en el cluster, así que alguien pega otra copia en los secretos de la CI. A los pocos meses, nadie sabría decirte cuántas copias hay.

Nada de esto es dejadez. Cada paso es razonable el día que se da: el equipo es pequeño, hay confianza y el trabajo tiene que salir. El fichero tampoco tiene la culpa. Es una credencial pensada para montar el cluster, y acaba siendo la que usa todo el mundo para trabajar.

Lo que cuesta

Mientras todo va bien, no se nota. Se nota el día que alguien te hace una pregunta.

¿Quién lo tiene? Nadie lo sabe a ciencia cierta. Hay copias en portátiles, en la configuración de la CI y en hilos viejos del chat. Y lista no hay ninguna.

¿Quién ha hecho esto? En la auditoría del cluster pone kubernetes-admin, o el nombre que lleve el fichero, y es el mismo para todas las personas y todos los pipelines. Sabes que ha pasado algo, pero no quién ha sido.

¿Se puede retirar? Rápido, no. Un kubeconfig de administrador suele llevar un certificado de cliente, y Kubernetes no revoca certificados: el que se ha emitido vale hasta que caduca, a menudo al cabo de un año o más. Para retirar el fichero hay que rotar las credenciales de todo el cluster y repartir uno nuevo. Eso ya es un proyecto, y los proyectos se aplazan.

Alguien se va. Aunque se despida con un abrazo, se lleva una copia en el portátil. Para estar seguro de que ya no sirve, no queda otra que hacer esa misma rotación en cada cluster al que da acceso el fichero. Es fácil dejarlo para otro día, y mientras tanto la copia sigue valiendo.

La otra forma

Lo que yo quería se dice rápido: una credencial por persona, por pipeline y por agente, cada una con nombre y apellidos y una fecha de caducidad, y que el cluster vea quién hay de verdad detrás de cada petición.

Para eso está kubelatch. Hace de proxy delante del API server de cada uno de tus clusters, y cada credencial que emite es de alguien concreto. Una persona recibe su kubeconfig con un token klt_ que caduca solo: por defecto, a los 30 días como mucho. Un job de GitHub Actions canjea el token OIDC que le da GitHub por una credencial de una hora, sin que haya que guardar ningún secreto en el repositorio. Un agente de IA entra por el servidor MCP de kubelatch de dos maneras: como un bot creado por un administrador, o en tu nombre, con tus permisos recortados y durante unas horas.

Cuando llega una petición, kubelatch comprueba el token, la registra y la reenvía al cluster suplantando a quien la ha hecho. Para el API server, quien pide ya no es un admin compartido: es user:ana, con los grupos de los permisos que Ana tiene activos. Cada verbo se sigue autorizando con el RBAC del propio cluster; kubelatch solo le dice al cluster quién pregunta. En Por qué un proxy tienes los motivos de esta decisión y lo que cuesta.

Con esto ya puedes contestar a las preguntas de antes. En «Credenciales» ves de quién es cada una, a qué clusters llega, hasta cuándo vale y cuándo se usó por última vez. Si revocas una, la siguiente petición ya recibe un 401. Y si tienes configurada la GitHub App, cuando alguien sale de tu organización de GitHub, su cuenta se deshabilita sola: se revocan sus credenciales y se le corta el acceso a cualquier agente que trabaje en su nombre. No hay nada que rotar. El detalle está en Identidad.

Lo que kubelatch no es

• No es un inicio de sesión único (SSO). No tiene proveedor de identidad propio: se entra con GitHub, a través de una GitHub App de tu organización, o con cuentas locales.
• No es una service mesh. No se mete en medio de tus cargas de trabajo, y tus aplicaciones no dependen de él.
• No es un bastión para todo. Vigila una sola puerta, la API de Kubernetes, y registra lo que entra por ella. No graba sesiones ni hace de puente hacia redes privadas.

Y es pequeño a propósito: un binario de Go y Postgres. La interfaz web, la API, el proxy y el reconciliador de RBAC comparten proceso, y todo el estado se guarda en la base de datos. En cada cluster le bastan dos ServiceAccounts y la API estándar de Kubernetes: sin tocar los flags del API server, sin instalar nada en los nodos y sin un agente por cluster. Por eso funciona igual en EKS, GKE y AKS que en kubeadm, k3s, RKE2 o Talos.

Eso sí, hay una pega. Las personas y la CI hacen todas sus peticiones a través de kubelatch, así que, si kubelatch se cae, se quedan sin ese acceso; tus cargas de trabajo, en cambio, siguen funcionando. Por eso kubelatch nunca debe ser la única forma de entrar en un cluster. Ten preparado un acceso nativo de emergencia a cada uno y comprueba que funciona: la identidad de administrador de tu proveedor cloud o, en un cluster autogestionado, el kubeconfig de administrador en un gestor de secretos con acceso auditado. Lo que entra por esa puerta queda en la auditoría nativa del cluster, no en la de kubelatch. Así que el fichero del principio no desaparece: vuelve a guardarse bajo llave para el día que haga falta.

Pruébalo

La forma más rápida de verlo funcionar es el tutorial en local. En tu propia máquina, con contraseñas locales y un cluster kind de usar y tirar, te das un permiso, usas kubectl a través de kubelatch, encuentras cada petición en «Auditoría» y revocas la credencial: el siguiente kubectl ya da un 401. Son unos quince minutos, más lo que tarden las descargas la primera vez.

kubelatch es gratis para 2 clusters y 5 personas, sin registro y sin límite de tiempo; los bots, los pipelines y los agentes no cuentan como personas. El resto está en Precios. kubelatch lo hace una sola persona, en España: si algo de lo que cuento aquí no cuadra con lo que ves al probarlo, escríbeme.