kubelatch encima del SSO que ya tienes¶

Muchos clusters ya tienen su propio inicio de sesión: EKS con IAM o con un proveedor OIDC, AKS con Entra ID, GKE con cuentas de Google, un k3s o un kubeadm con las opciones --oidc-*. Su RBAC ya está escrito para esos usuarios y grupos. Esta página explica cómo se monta kubelatch encima de ese inicio de sesión en vez de al lado, y qué sigue haciendo a su manera.

Dos mundos en paralelo¶

Por defecto, kubelatch manda al cluster nombres propios. Una persona entra como user:<login>, y cada permiso es un grupo como kubelatch:ns:apps:developer, enlazado por un binding que escribe kubelatch. Dentro del cluster es un mundo aparte: el audit log del apiserver nombra dos veces a Ana (oidc:ana@acme.com cuando entra con el SSO del cluster, user:ana cuando entra por kubelatch), y el equipo mantiene dos juegos de bindings para las mismas personas.

El login con OIDC ya deja entrar en kubelatch con el mismo proveedor de identidad. Dos piezas más llevan esa identidad hasta dentro del cluster.

Qué cambia¶

• Roles nativos. Un rol nativo nombra uno o varios grupos que el cluster ya conoce, como oidc:developers. Un permiso de ese rol es pertenencia temporal a esos grupos: el proxy los manda como Impersonate-Group mientras dura el permiso, y se aplican los bindings que el cluster ya tiene para ellos. kubelatch no escribe ningún binding para un rol nativo. La caducidad, la revocación, las aprobaciones y la auditoría funcionan como en cualquier otro rol.
• La identidad propia del cluster. Cada cluster tiene una plantilla de identidad que dice cómo nombra kubelatch a las personas allí, por ejemplo oidc:{email}. Con ella, Ana entra en ese cluster como oidc:ana@acme.com venga por donde venga, así que el audit log del apiserver y los bindings a usuarios la nombran igual. La plantilla por defecto, user:{login}, conserva los nombres de siempre.

Ninguna de las dos pide tocar tu RBAC ni un manifiesto de bootstrap nuevo: kubelatch solo lee los bindings que tiene el cluster, con los permisos que ya tenía. Los roles nativos necesitan el bootstrap actual (v2), igual que los personalizados.

Qué no cambia¶

• kubelatch sigue entrando en el cluster con su propia ServiceAccount y actúa por cada persona suplantándola. El SSO del cluster no ve la credencial de kubelatch de la persona, y kubelatch no ve los tokens de su SSO.
• El proxy solo puede suplantar un nombre mientras hay un permiso activo que lo da: cada grupo nativo y cada nombre que rinde la plantilla está en la lista de suplantación del cluster solo durante ese tiempo, y sale en la pasada siguiente. Cuando un permiso caduca, el proxy deja de mandar sus grupos al momento.
• Impersonate-Uid sigue llevando el identificador propio de la cuenta, así que el audit log del apiserver distingue a dos personas aunque su nombre cambie o coincida.
• Los bots entran siempre como bot:<nombre>.

El nombre arrastra todo lo que el cluster le enlaza¶

Hasta ahora, el RBAC que se aplicaba a una petición que pasaba por kubelatch era justo el que kubelatch escribía, porque solo kubelatch usaba sus nombres. Un grupo nativo o un nombre de usuario rendido cambian eso: el cluster aplica todos los bindings que tiene para ese nombre, los escriba quien los escriba. Si el cluster enlaza oidc:platform-admins a cluster-admin, un rol nativo con ese grupo da cluster-admin; si enlaza oidc:ana@acme.com a cluster-admin, lo da cualquier permiso de Ana en ese cluster, aunque sea un viewer de una hora.

kubelatch no lo prohíbe, porque es la forma habitual en que los clusters gestionados dan su acceso a los administradores. Lo acota igual que el rol cluster-admin:

• Un permiso que convertiría a alguien en cluster-admin por una ClusterRoleBinding del cluster necesita una caducidad de 8 horas como máximo. kubelatch lee las ClusterRoleBindings del cluster en el momento de conceder, nunca de una caché, y rechaza el permiso si no puede leerlas.
• Un rol nativo cuyo grupo está enlazado a cluster-admin no puede ser un permiso de grupo: los miembros futuros lo heredarían sin ninguna comprobación.
• Cada reconciliación vuelve a leer los bindings. Un grupo o un usuario enlazado a cluster-admin que algún permiso activo da sin esa caducidad se queda fuera de la lista de suplantación, y el cluster pasa a «Error» diciendo quién y por qué. Así se cubre también un binding añadido después de conceder.
• Los agentes de IA nunca reciben un rol nativo, y entran siempre en un cluster con el nombre de la persona en kubelatch, user:<login>, nunca con el nombre que el cluster da a la persona (Agentes de IA).

Lo que kubelatch lee es RBAC: las ClusterRoleBindings cuyo rol es el ClusterRole cluster-admin. No ve un ClusterRole con otro nombre que dé lo mismo, ni lo que concede un autorizador ajeno a RBAC, como los roles de IAM en GKE, Azure RBAC en AKS o las políticas de acceso de EKS. Elige los grupos de un rol nativo, y la plantilla de un cluster, sabiendo qué da el cluster a esos nombres; El SSO del cluster, proveedor a proveedor explica cómo nombra cada proveedor.

Cuándo usar cada cosa¶

Se combinan: un cluster con la plantilla oidc:{email} admite roles de sistema, personalizados y nativos por igual, y un rol nativo funciona también con la plantilla por defecto.