Los grupos de tu cluster, con fecha de caducidad

Si el RBAC de tus clusters ya está escrito para los grupos de tu SSO, desde la 0.46 kubelatch puede meter a alguien en uno de esos grupos hasta la fecha que elijas, y mientras tanto se le aplican los bindings que ya tienes. Con el login por OIDC, además, la gente nueva se da de alta sola con el correo de la empresa. La 0.47 pule las dos cosas, cambia un valor por defecto de la API y corrige un fallo de seguridad: te cuento qué revisar antes de actualizar y qué sigue sin ver kubelatch.

Los grupos que tu cluster ya conoce

Pongamos un cluster kubeadm con --oidc-*, en el que un RoleBinding da edit en el namespace payments al grupo oidc:payments-devs. En EKS, AKS o GKE pasa lo mismo con los grupos de cada proveedor, cada uno con su formato. Hasta la 0.45, kubelatch iba por libre. Cada permiso era un grupo suyo, como kubelatch:ns:payments:developer, con un binding que escribía él, y en la auditoría del apiserver Ana salía con dos nombres, oidc:ana@acme.com y user:ana.

La 0.46, del 20 de octubre, trae lo que la entrada de la 0.45 dejaba para la fase 1. Lo primero es el rol nativo, que nombra entre uno y 20 grupos que el cluster ya conoce. Concederlo es meter a la persona en esos grupos por un tiempo: mientras dura el permiso, el proxy los manda en Impersonate-Group y el cluster aplica los bindings que ya existen. kubelatch no escribe ningún binding ni ningún ClusterRole, y en cuanto el permiso caduca deja de mandar esos grupos. La revocación, las aprobaciones y la auditoría funcionan como con cualquier otro rol.

Si Ana necesita edit en payments hasta el viernes, ya no hace falta escribir un rol personalizado que copie lo que da edit, ni meterla en el grupo del directorio y apuntarte que el viernes hay que sacarla: le concedes hasta el viernes un rol nativo con oidc:payments-devs y el permiso caduca solo. Al crear el rol, eliges un cluster en «Conocidos en» y kubelatch te enseña los grupos que nombran sus bindings.

Con el nombre que usa tu cluster

La otra mitad del cambio es el nombre con el que entra cada persona. Cada cluster tiene ahora una plantilla de identidad con la que eliges ese nombre. Con oidc:{email}, Ana es oidc:ana@acme.com entre por kubelatch o directamente por el SSO del cluster, así que le valen los bindings que la nombran, y en la auditoría del apiserver sale con un solo nombre. La plantilla por defecto, user:{login}, lo deja todo como estaba, y antes de guardar otra, la vista previa enseña con qué nombre entrará cada persona.

En la 0.46, bastaba una cuenta que la plantilla no pudiera nombrar, como una sin correo verificado en un cluster con {email}, para dejar el cluster en error. En la 0.47 ya no: el cluster sigue listo, los demás siguen trabajando y esa cuenta recibe un 403 que explica qué le falta.

cluster-admin, 8 horas como mucho

El cluster aplica a un grupo o a un nombre todos los bindings que tenga para él, los haya escrito quien los haya escrito. Si enlaza oidc:platform-admins a cluster-admin, un rol nativo con ese grupo da cluster-admin; si enlaza oidc:ana@acme.com, lo da cualquier permiso de Ana en ese cluster, aunque sea un viewer de una hora. kubelatch no lo prohíbe, porque así suelen dar acceso los clusters gestionados a sus administradores, pero lo acota como al rol cluster-admin:

• Ese permiso tiene que caducar en 8 horas como mucho. kubelatch lo comprueba al conceder, leyendo en directo las ClusterRoleBindings del cluster, y si no puede leerlas, lo rechaza.
• No se puede dar como permiso de grupo, porque cada miembro futuro lo heredaría sin esa comprobación. Desde la 0.47, el formulario del grupo lo enseña desactivado, con el motivo, en cuanto eliges el cluster.
• Cada 10 minutos, y con cada cambio, kubelatch vuelve a leer los bindings. Si alguien enlaza después uno de esos grupos a cluster-admin y algún permiso lo da sin caducar en 8 horas, o lo da un permiso de grupo, ese grupo se queda fuera de lo que el proxy puede suplantar y el cluster pasa a «Error» diciendo quién y por qué.
• Los agentes de IA nunca reciben un rol nativo.

La gente nueva entra sola

Lo segundo son las altas sin invitación. Con el login por OIDC, añades un dominio en «Acceso por dominio», dentro de «Usuarios», y quien entre con un correo verificado de ese dominio recibe una cuenta en el grupo que elijas, con una caducidad opcional para esa pertenencia. Llega a «Inicio» con los permisos del grupo, y la tarjeta «Tu conexión» le marca los pasos hasta su primer kubectl: instalar la CLI y entrar, tener un permiso y probarlo.

Si su dominio no tiene regla, o la regla no puede crearle la cuenta, llega a «Pedir unirse» y puede enviar una solicitud. Un administrador la aprueba en «Usuarios», con un grupo, un permiso directo o nada, o la deniega con una nota que solo ven los administradores. Las dos vías respetan el tope de cinco personas de Free y quedan en el registro de control.

Eso sí, una regla da los permisos del grupo a cualquiera de la empresa en su primer acceso: apúntala a un grupo con pocos permisos, como viewer en los namespaces que usa todo el mundo, y lo demás dalo a mano. Y como los logins se reparten por orden de llegada entre todos los dominios permitidos (bob@contractor.io puede quedarse con el bob que tus bindings pensaban para bob@acme.com), si la plantilla de un cluster usa {login} y sus bindings nombran usuarios, cámbiala por una con {email}.

Antes de actualizar a la 0.47

La 0.47 salió el 21 de octubre y corrige un fallo de seguridad de severidad media: quien pudiera interceptar las conexiones salientes de kubelatch (a tu proveedor de identidad, a GitHub, al correo o a un cluster) podía conseguir que kubelatch aceptara un certificado falso de una autoridad de certificación en la que ya no se confía. La 0.47 está compilada con Go 1.26.10, que lo arregla. Las versiones anteriores están afectadas, así que toca actualizar; antes, revisa esto:

• Un permiso creado por la API sin expires_at caduca ahora a los 30 días, como en la interfaz; antes no caducaba nunca. Si algún script contaba con eso, tiene que mandar "never_expires": true.
• Recarga las pestañas de kubelatch que tengas abiertas: una página cargada antes de actualizar manda «Nunca» como un permiso de 30 días.
• Los roles nativos necesitan el manifiesto de bootstrap actual. Si la ficha del cluster dice que el suyo es v1, sigue Actualizar el bootstrap.
• Con dos réplicas o más, termina el rollout antes de cambiar la plantilla de un cluster o de añadir un dominio; si no, la réplica antigua y la nueva se pisan el trabajo en cada pasada.

Y al entrar verás el logo de cada proveedor en su botón; si tu issuer está en un dominio propio, elige el logo con OIDC_ICON (config.oidc.icon en el chart).

Lo que esto no resuelve

• kubelatch solo ve RBAC, y para la regla de las 8 horas, solo las ClusterRoleBindings al ClusterRole cluster-admin: no ve un ClusterRole con otro nombre que dé lo mismo, ni lo que conceden el IAM de GKE, Azure RBAC en AKS o las políticas de acceso de EKS. El SSO del cluster, proveedor a proveedor cuenta cómo nombra cada uno los grupos.
• Lo que entra directamente por el SSO del cluster no pasa por kubelatch: kubelatch no le pone fecha de caducidad ni lo registra en su auditoría.
• Las bajas siguen siendo cosa tuya. Quitar una regla de dominio retira las pertenencias que creó, pero deja las cuentas, y el proveedor no le dice a kubelatch quién se ha ido: pulsa «Deshabilitar» en la cuenta de quien se va.
• kubelatch sigue en public preview: le faltan piezas, solo se da soporte a la última versión y aún no hay compromiso de estabilidad entre versiones, como muestra el cambio de la API de la 0.47.

Pruébalo

Si ya tienes kubelatch, lee las notas de versión y actualiza a la 0.47 con Actualizar kubelatch. Después, kubelatch encima del SSO que ya tienes explica cuándo te conviene un rol nativo y cuándo una plantilla, y Roles nativos trae los pasos para crear el primero. Todo esto funciona igual en Free y en Pro.

Si todavía no lo tienes, el tutorial local lo monta 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.

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.