Grupos¶

Un grupo da los mismos permisos a varias personas y bots. Tiene miembros, cada uno con una caducidad opcional, y permisos del grupo, cada uno un cluster, un rol y un ámbito con su propia caducidad. Aquí ves cómo crear uno, llenarlo y vaciarlo en «Grupos», y qué provoca cada cambio en los clusters.

Cómo funciona un grupo¶

kubelatch convierte cada combinación de un miembro y un permiso del grupo en un permiso de ese miembro: un permiso derivado. Cuatro miembros y cinco permisos del grupo son veinte permisos derivados, que siguen al grupo en todo momento:

• Quien entra recibe al momento todos los permisos del grupo.
• Un permiso que se añade al grupo llega al momento a todos sus miembros.
• Quien sale, y lo que el grupo deja de dar, se revoca al momento.

Cada cambio reconcilia los clusters que toca, igual que un permiso directo. Para el proxy, el reconciliador, la CLI y la auditoría, un permiso derivado es un permiso como cualquier otro. En «Permisos» es de solo lectura: se cambia desde su grupo.

Los permisos directos siguen existiendo, para accesos puntuales y para cluster-admin. Una persona puede tener el mismo rol en el mismo ámbito de forma directa y a través de un grupo, o a través de dos grupos; es válido, y «Permisos» señala el que sobra (Solapamientos).

Los grupos no tienen límite de edición.

Antes de empezar¶

• Eres administrador de kubelatch.
• Un permiso del grupo sigue las mismas reglas que uno directo: namespaces protegidos, ámbito, PSA y roles personalizados con el bootstrap actual (Las reglas).

Crear un grupo¶

1. Abre «Grupos» y pulsa «Crear un grupo». El formulario se abre en un panel a la derecha. La paleta de comandos (⌘K) también tiene «Crear un grupo» y cada grupo por su nombre; el enlace «Créalo como grupo», bajo el formulario de «Permisos», abre el mismo panel.

2. Rellena el formulario:

   Campo	Qué poner
   «Nombre»	Lo que se lee en la interfaz, de hasta 80 caracteres.
   «Id»	Se propone a partir del nombre mientras lo escribes. Puedes editarlo hasta crear el grupo: minúsculas, dígitos y guiones, de 1 a 63 caracteres, empezando por letra o dígito. Después no cambia, y no se reutiliza nunca, ni tras eliminar el grupo.
   «Descripción»	Opcional, de hasta 200 caracteres.

3. Pulsa «Crear». Llegas a la ficha del grupo con el aviso «Grupo «…» creado.»

La ficha del grupo tiene arriba «Editar» (nombre y descripción) y «Eliminar», y cuatro cifras: «Miembros» y «Permisos del grupo» (los no caducados), «Permisos efectivos» (los permisos derivados activos ahora) y «Clusters» (donde el grupo tiene permisos activos). Debajo van las tarjetas «Miembros» y «Permisos del grupo», y «Detalles», con el id, la fecha de creación y el enlace «Ver los N permisos efectivos».

Añadir miembros¶

1. En la ficha del grupo, en «Miembros», pulsa «Añadir miembros».
2. En «Cuentas», elige una o varias en el selector «Añadir cuenta…». Cada una aparece como una etiqueta que puedes quitar. Pueden entrar personas y bots; las cuentas deshabilitadas y los miembros actuales no aparecen.
3. En «La pertenencia caduca», elige 8 h, 7 días, 30 días, 90 días, «Fecha…» o «Nunca». «Nunca» es el valor por defecto, porque cada permiso del grupo lleva su propia caducidad. Todas las cuentas que añades de una vez reciben la misma.
4. Pulsa «Añadir N miembros».

Cada miembro nuevo recibe al momento los permisos del grupo. El alta es todo o nada: si una cuenta no puede entrar, no entra ninguna, y el panel dice «Rechazado en «…».» bajo el botón, con el motivo.

Al entrar alguien, kubelatch vuelve a comprobar los permisos del grupo como si concediera cada uno directamente al miembro nuevo. Si uno ya no pasa, por ejemplo porque alguien quitó la etiqueta de PSA a su namespace, no entra nadie hasta que revocas ese permiso del grupo o arreglas el namespace. El panel entonces señala ese permiso, no una cuenta: «Este permiso del grupo impide añadir miembros: developer en shop de prod. Revócalo o corrígelo antes.»

La columna «Nota» muestra la nota de un miembro. El panel no la pide; solo la fija la API (note en POST /api/groups/{id}/members).

Para añadir una sola cuenta, abre su ficha en «Usuarios» y usa «Añadir a un grupo» en su tarjeta «Acceso»: elige el «Grupo» y cuándo caduca la pertenencia («Nunca» por defecto), y pulsa «Añadir». La tarjeta también lista los grupos en los que está la cuenta, cada uno con la caducidad de su pertenencia.

Añadir permisos del grupo¶

1. En la ficha del grupo, en «Permisos del grupo», pulsa «Añadir permisos».
2. Rellena el mismo formulario que en Conceder permisos, sin cuentas: «Cluster», «Ámbitos» (varios namespaces a la vez, o «todo el cluster (*)»), el rol en «Qué», «Hasta cuándo» (30 días por defecto) y «Nota».
3. Una línea cuenta lo que se va a añadir, por ejemplo «2 permisos del grupo: developer en apps, web de kind, hasta …». Los que el grupo ya tiene quedan fuera, y el formulario lo dice.
4. Pulsa «Conceder N permisos».

Todos los miembros los reciben al momento. Si se rechaza una entrada, no se añade nada, y el formulario la nombra bajo el resumen.

Dos caducidades¶

Un permiso derivado caduca en la primera de dos fechas: la de la pertenencia y la del permiso del grupo.

Cuando pasa la fecha, el permiso derivado pasa a «Caducados» en «Permisos», como cualquier otro. Una pertenencia o un permiso del grupo caducados siguen en la ficha del grupo, marcados «Caducada», para que puedas prorrogar la pertenencia o quitar lo que sobre.

Para prorrogar a un miembro, elige «Prorrogar» en el menú de su fila, elige la nueva caducidad y pulsa «Guardar cambios». La nueva fecha se aplica en el sitio a todos los permisos que le da el grupo: el mismo permiso, con su nueva caducidad. Un permiso derivado caducado vuelve a la vida igual, y antes se repite la comprobación de los permisos del grupo que se hace al entrar. La sesión de un agente de IA cuyo permiso derivado salía del caducado no vuelve: su propia caducidad quedó acotada por la fecha antigua.

Para prorrogar un permiso del grupo, elige «Prorrogar» en el menú de su fila. Cada miembro recibe la nueva caducidad, acotada por su propia pertenencia, y un permiso caducado vuelve para ellos. kubelatch comprueba el permiso otra vez como si fuera nuevo: el máximo del rol, Pod Security y los namespaces protegidos. Mientras no revoques un permiso, aunque haya caducado, el grupo sigue teniéndolo y el formulario lo deja fuera.

Quitar a un miembro o revocar un permiso del grupo¶

• «Quitar», en el menú de un miembro, pide confirmación: «Revoca los N permisos que le da el grupo.»
• «Revocar», en el menú de un permiso del grupo, pide confirmación: «Sus N miembros pierden el permiso.»

Las dos revocan los permisos derivados afectados y reconcilian sus clusters en segundos. Las credenciales de la persona siguen valiendo para el resto de sus permisos. Si se queda sin ninguno en un cluster, el proxy responde 403 … has no active permissions on cluster …. Un agente de IA cuyo techo salía de un permiso revocado lo pierde en su siguiente llamada.

La auditoría guarda toda la historia: group.member.remove o group.grant.revoke, y un grant.revoke por cada permiso derivado, con el grupo, el miembro y el permiso del grupo (El plano de control). Los permisos revocados siguen en «Revocados» de «Permisos».

Eliminar un grupo¶

«Eliminar», en la ficha del grupo o en el menú de su fila en «Grupos», abre una confirmación con las cifras reales, leídas al abrirla: «Quita 4 miembros y revoca 20 permisos. Los clusters se reconcilian al momento.» Un grupo vacío dice «El grupo no tiene miembros ni da permisos.» El botón «Eliminar» espera a tener las cifras.

Eliminar quita a todos los miembros, revoca todos los permisos del grupo y todos los permisos derivados, y reconcilia los clusters. El id no se reutiliza. Las filas de auditoría y los permisos revocados se conservan.

Cuentas deshabilitadas¶

Una cuenta deshabilitada conserva sus pertenencias y sus permisos derivados, igual que conserva los directos. Ninguno cuenta mientras está deshabilitada: el miembro aparece con «Cuenta deshabilitada» en la ficha del grupo. «Habilitar» los recupera todos sin tocar el grupo (Deshabilitar y habilitar).

Una cuenta deshabilitada no puede entrar en un grupo: no aparece en los selectores, su ficha no tiene «Añadir a un grupo», y la API responde 409 group.subject_disabled.

Ver de dónde viene un permiso¶

• «Permisos»: la columna «Origen» dice directo, o el nombre del grupo como enlace a su ficha. El menú de un permiso derivado ofrece «Ver grupo» en lugar de «Revocar» (Revocar un permiso).
• La ficha del grupo: «Ver los N permisos efectivos» abre «Permisos» solo con los permisos derivados de ese grupo (?group=<id>).
• «Usuarios»: la columna «Acceso», por ejemplo 2 grupos · 1 directo, y la tarjeta «Acceso» de la ficha de la cuenta, que lista sus grupos con la caducidad de cada pertenencia (Usuarios y bots).
• «Inicio»: cada permiso de las tarjetas de «Mis accesos» que viene de un grupo dice «vía grupo …» bajo el rol.

Por API¶

Todo lo anterior existe en la API JSON bajo /api/groups, y GET /api/grants?group=<id> lista los permisos derivados de un grupo. Las rutas están en API HTTP y los errores en Errores.