Entra en kubelatch con la cuenta de tu empresa

Desde la 0.45, la gente entra en kubelatch con la cuenta de la empresa: Google Workspace, Entra ID, Okta, Keycloak u otro proveedor de OpenID Connect que publique su documento de descubrimiento. Ese SSO ya resuelve quién entra en tus clusters; kubelatch pone lo demás: hasta cuándo dura cada permiso, qué permite hacer y un registro de cada petición. Te cuento qué cambia al activarlo y lo que se queda fuera, como las bajas, que siguen siendo cosa tuya.

Tu cluster ya sabe quién entra

Si tus clusters están en EKS, AKS o GKE, es fácil que la gente ya entre en ellos con la cuenta de la empresa: en EKS, con IAM Identity Center o con un proveedor OIDC; en AKS, con Entra ID; en GKE, con Google. Tus bindings ya dan permisos a usuarios y grupos que salen de ahí, así que lo de quién entra está resuelto.

Pero ese SSO no pasa de ahí. Un binding al grupo platform-admins da cluster-admin hoy, dentro de un mes y dentro de un año a quien siga en el grupo. Si tienes tres nubes, tienes tres auditorías, cada una con su formato. Y el agente de IA que trabaja en tu terminal entra con tu kubeconfig y puede todo lo que puedes tú.

De eso se encarga kubelatch. Un permiso dura 30 días si no eliges otra fecha en la interfaz; también puedes elegir «Nunca», salvo en cluster-admin, que no pasa de 8 horas. Cada credencial tiene dueño y caduca: por defecto, 30 días como mucho para una persona, 90 para un bot y una hora para un job de CI. Y cada petición que pasa por kubelatch deja una fila legible, igual en todas las nubes.

Hasta ahora, para entrar en kubelatch hacía falta GitHub o una contraseña local. Desde la 0.45 puedes entrar con el mismo proveedor que el cluster, si es compatible con OpenID Connect. Con Google, Entra ID, Okta o Keycloak, sí. Con el directorio propio de IAM Identity Center, no: a las aplicaciones les ofrece SAML, y SAML está en el apartado «Bajo demanda» del roadmap. Si detrás de Identity Center tienes Okta, Entra ID o Google, kubelatch se da de alta directamente en ese proveedor.

Una aplicación más en tu proveedor

kubelatch no sustituye al SSO del cluster ni pone otro encima. Se da de alta en tu proveedor como una aplicación más, igual que Argo CD o Grafana, y la gente entra con la sesión que ya tiene abierta en el navegador. Al activarlo:

• La pantalla de inicio de sesión muestra «Entrar con» y el nombre que pongas en displayName («Entrar con SSO» si no pones ninguno). Si también tienes el login con GitHub, salen los dos botones.
• Cada cuenta que ya existe se vincula sola la primera vez que su titular entra, si tiene el mismo correo y el proveedor lo da por verificado. A una cuenta sin correo tienes que ponerle uno antes, o mandarle un enlace de vinculación. El login de kubelatch no cambia: los clusters siguen viendo a user:ana y nadie pierde sus permisos.
• kubelatch login sigue abriendo el navegador, y solo pasa por el proveedor si hace falta.
• Las contraseñas dejan de valer, salvo las de las cuentas break-glass.

En Kubernetes, el client ID y su secreto van en un Secret, y lo demás, en el config.oidc del chart. El chart no acepta un issuer sin allowedDomains (los dominios de correo que pueden entrar), ni al revés. Si tu proveedor usa una CA privada, el nuevo extraEnv del chart te deja apuntar SSL_CERT_FILE a ella. La guía Login con OIDC trae los pasos para Google Workspace, Entra ID, Okta, Keycloak, Authentik y Auth0.

Por defecto, el primer acceso vincula cualquier cuenta habilitada con el mismo correo, y así quitas las contraseñas sin mandar un enlace a cada persona. Si en tu directorio cada persona puede cambiarse el correo, pon autolink: off en config.oidc: cada cuenta se vincula entonces con un enlace que mandas tú. La guía explica cuándo basta con invited, que solo vincula las cuentas que aún no han entrado o tienen una invitación pendiente.

Primero, una cuenta break-glass

Si activas OIDC sin ninguna cuenta break-glass y algo falla (el proveedor, su configuración o la vinculación de tu administrador), ningún administrador puede entrar hasta que marques una desde la CLI del servidor, así que márcala antes. Cambia admin por el login de tu administrador; $MGMT_KUBECONFIG es el kubeconfig del cluster donde está instalado kubelatch:

kubectl --kubeconfig "$MGMT_KUBECONFIG" -n kubelatch exec -it deploy/kubelatch -- /kubelatch-server user set-break-glass admin

Esa cuenta es también tu forma de entrar si el proveedor se cae o su configuración se rompe: kubelatch comprueba esa contraseña sin pasar por el proveedor, y la CLI del servidor tampoco lo necesita. La pega es que no tiene doble factor, así que ten las justas, con contraseñas largas guardadas en el gestor de secretos.

Lo que esto no resuelve

• No hay alta automática. A quien no tiene cuenta con su correo se le rechaza, y la pantalla le dice a quién pedirla, según config.accessContact. Las cuentas se siguen creando en «Usuarios»; entrar sin esperar a que alguien te invite está en la fase 1 del roadmap.
• No hay bajas automáticas. El proveedor no le pasa a kubelatch la lista de miembros. Cuando alguien se va, pulsa «Deshabilitar» en su cuenta: cierra sus sesiones y revoca sus credenciales al momento. Mientras no lo hagas, lo que ya tiene sigue valiendo hasta que caduque, aunque el proveedor haya cerrado su cuenta: 12 horas la sesión web y, con los valores por defecto, 12 horas la de la CLI y hasta 30 días cada credencial.
• El doble factor lo pone tu proveedor. kubelatch apunta cómo se autenticó cada persona, si el proveedor se lo dice, pero no exige nada.
• La identidad dentro del cluster sigue aparte. Los bindings que tu cluster da a los grupos del proveedor son cosa del cluster, y lo que entra por ahí no pasa por kubelatch. Cuando Ana entra por kubelatch, el cluster ve a user:ana, no su correo. En la fase 1, un permiso de kubelatch podrá meter a alguien durante un tiempo en un grupo que tu cluster ya usa, y el RBAC que ya tienes valdrá mientras dure.
• kubelatch está en public preview. Le faltan piezas, que están en el roadmap, solo se da soporte a la última versión y todavía no hay compromiso de estabilidad entre versiones.

Pruébalo

Si ya tienes kubelatch, sigue Login con OIDC: primero la cuenta break-glass, después la aplicación en tu proveedor y, al final, un helm upgrade a la 0.45 con el Secret y config.oidc a la vez. Con Google, cuenta con que una URI de redirección nueva puede tardar desde cinco minutos hasta unas horas en funcionar. Funciona igual en Free y en Pro, y vincular no crea cuentas, así que no suma para el límite de cinco personas de Free.

Si todavía no lo tienes, con el tutorial local lo montas en tu máquina, con un cluster de kind de usar y tirar, en unos quince minutos, más las descargas de la primera vez. El tutorial usa contraseñas locales; el login con OIDC lo añades después con la guía.

kubelatch se desarrolla en Picaporte Labs, en España. Si algo no cuadra con lo que ves, escríbeme a hola@picaportelabs.com o a hello@kubelatch.com.