Conceder permisos¶

Un permiso da a una persona o a un bot un rol en un cluster, sobre un namespace o sobre todo el cluster. El rol es uno de los seis roles de sistema, los niveles, o un rol personalizado. Un permiso se concede de forma directa, aquí, o a través de un grupo, que da los mismos permisos a todos sus miembros. Aquí ves cómo conceder y revocar permisos en «Permisos», cómo leer la página y qué reglas aplica kubelatch.

Qué hace cada nivel y por qué existen estas reglas está en Roles de sistema y Modelo de seguridad; los roles personalizados, en Roles y Gestionar roles.

Antes de empezar¶

• El sujeto existe y está habilitado (Usuarios y bots).
• El cluster está registrado y enrolado: dice «Listo» o «Error», no «Sin enrolar» (Registrar un cluster).
• Para developer, debugger, admin o un rol personalizado que exige Pod Security, el namespace tiene la etiqueta pod-security.kubernetes.io/enforce con baseline o restricted.
• Para un rol personalizado, el cluster tiene el manifiesto de bootstrap actual (Actualizar el bootstrap).

Conceder un permiso¶

El formulario concede un rol a varias cuentas en varios clusters, cada uno con sus ámbitos, de una vez: un permiso por cuenta, cluster y ámbito, y se concede todo o nada.

1. Abre «Permisos» y pulsa «Conceder permisos». El formulario se abre en un panel a la derecha, en tres grupos: «Quién y dónde», «Qué» y «Hasta cuándo».

2. Rellena el formulario:

   Campo	Qué poner
   «Cuentas»	Una o varias personas o bots, elegidos en el selector «Añadir cuenta…». Cada una aparece como una etiqueta que puedes quitar. Las cuentas deshabilitadas no aparecen.
   «Dónde»	«Clusters concretos», por defecto, o, en Pro, «Un entorno» o «Una etiqueta»: el permiso sigue entonces a todos los clusters de ese entorno o con esa etiqueta (Permisos sobre un conjunto). En Free, las dos últimas llevan «Pro» y «Ver Pro».
   «Clusters»	Con «Clusters concretos»: uno o varios clusters enrolados, elegidos en el selector «Añadir cluster…»; uno «Sin enrolar» no aparece.
   «Ámbitos»	Bajo cada cluster elegido, una casilla por namespace, con su nivel PSA; marca los que necesites. Primero va «todo el cluster ()» cuando el rol lo admite, y va solo en su cluster: marcarlo vacía y bloquea los namespaces de ese cluster. Un rol que solo se concede a todo el cluster, como cluster-admin, muestra «Ámbito» con «todo el cluster ()» y sin casilla. Los namespaces protegidos no aparecen.
   «Qué»	El rol, cada uno con su descripción debajo: primero los «Roles de sistema» (viewer, developer, debugger, secrets-reader, admin, cluster-admin), después los «Roles personalizados» y por último los «Roles nativos», cada uno con los grupos del cluster que manda. Un rol personalizado que el cluster no admite sale desactivado y dice por qué (Conceder un rol personalizado); un rol nativo, en Conceder un rol nativo.
   «Hasta cuándo»	8 h, 7 días, 30 días, 90 días, «Fecha…» o «Nunca», limitado a lo que admite el rol elegido. 30 días es el valor por defecto; «Fecha…» muestra el campo «Caducidad»; «Nunca» solo aparece para un rol sin máximo (todos menos cluster-admin). Para una persona en un cluster cuyo entorno tiene reglas, las opciones llegan hasta su máximo, sin «Nunca», y el valor por defecto es el del entorno: su duración, o «Por defecto de prod (2 h)» si no coincide con ninguna.
   «Motivo»	Por qué se concede. Lo ven la persona y la auditoría. Va en todos los permisos del lote.
   «Ticket»	El ticket que lo respalda: una URL https://, una clave como INC-123 o un número como #512. Una clave se guarda en mayúsculas. Con KUBELATCH_TICKET_URL configurada, el campo enseña el enlace que será una clave o un número: «Se enlazará a …» (El motivo y el ticket).

3. Pulsa «Conceder N permisos». El panel se cierra, el aviso dice «Concedidos N permisos.» y los permisos aparecen en el mapa y en «Lista», en «Activos».

Un enlace puede abrir el panel con parte del formulario ya puesta. «Conceder permisos», en la tarjeta «Accesos» de la ficha de una cuenta, elige la cuenta en «Cuentas» (Usuarios y bots); «Conceder», en la tarjeta «Acceso» de la página de un cluster (para todo el cluster, o junto a un ámbito) y en cada fila de su tarjeta «Namespaces», elige el cluster y el namespace; marcar varios namespaces en esa tarjeta y elegir «Conceder en N namespaces» los elige todos. Lo que el formulario no ofrecería, una cuenta deshabilitada o un cluster «Sin enrolar» o que ya no existe, se deja vacío para que lo elijas tú.

En cuanto las cuentas, los clusters, los ámbitos, el rol y una caducidad válida están puestos, una línea cuenta lo que se va a conceder, cuentas por ámbitos, por ejemplo «4 permisos: developer en apps, web de kind a alice, bob, hasta …». Con varios clusters dice qué se multiplica: «6 permisos (2 cuentas × 3 ámbitos en 2 clusters): …». Debajo, admin, cluster-admin y «Nunca» tienen cada uno un aviso sobre lo que permite ese permiso.

Un permiso que ya existe, activo y directo, para la misma cuenta, rol y ámbito, queda fuera del recuento y se nombra: «alice en apps: ya concedido, así que se conceden 3.» Si existen todos, la línea dice «Todos estos permisos ya existen.» y el botón queda desactivado. Un permiso que la cuenta tiene a través de un grupo no cuenta como existente: se concede el directo, y la línea de uno de los dos dice que sobra (Solapamientos).

Elegir un rol cambia los ámbitos cuando hace falta (cluster-admin marca «todo el cluster (*)»; un rol solo de namespace lo desmarca), y lo dice debajo. Quitar un cluster quita sus ámbitos.

El motivo y el ticket son opcionales salvo que el entorno de los clusters los exija a personas y grupos. Entonces el campo dice dónde («Motivo · obligatorio en prod»), y «Conceder» se queda desactivado con lo que falta debajo: «prod pide un motivo.», y después «prod pide un ticket: una URL o una clave como INC-123.» Ahí un texto libre no vale como ticket. A un bot no se le pide ninguno de los dos.

Las reglas de un entorno se aplican en cuanto hay una persona entre las cuentas. Si dejan fuera la caducidad que elegiste, el formulario pone la que proponen y lo dice: «Caducidad cambiada a 8 h por las reglas de prod.» Con clusters de varios entornos, mandan el máximo más corto y la caducidad por defecto más corta. Una fecha que pasa del máximo deja el botón desactivado, con «prod admite permisos de una persona de 8 h como mucho.»

El formulario avisa antes de enviar si algo no cuadra, por ejemplo un namespace sin PSA. El servidor aplica las mismas reglas a cada entrada, 200 como mucho por lote: por encima, el botón queda desactivado y una línea dice «Como mucho 200 permisos de una vez: elige menos cuentas, ámbitos o clusters.» Si rechaza una, no se concede nada: el panel muestra el motivo, y una línea bajo el resumen nombra la entrada, por ejemplo «Rechazado en bob en web de kind.» Desaparece en cuanto cambias el formulario.

Bajo el resumen, «¿El mismo juego para más gente? Créalo como grupo» abre «Grupos» con su panel de creación: un grupo mantiene estos permisos al día para quien entre más tarde.

Cada permiso concedido reconcilia el cluster al momento: en uno o dos segundos el binding existe y la persona puede usarlo. Si el cluster está en «Error», mira Solución de problemas.

Cada permiso se traduce en un grupo que el proxy suplanta, por ejemplo kubelatch:ns:apps:viewer, o kubelatch:ns:apps:role-<id> para un rol personalizado. Lo ves al pulsar el rol en la línea del permiso, en cualquier lista, también en el «Inicio» de la persona.

Las reglas¶

Para trabajar en un namespace protegido, usa el acceso nativo de administrador del cluster: Cuentas y recuperación.

Dos avisos más:

• viewer en * ve nodos, PersistentVolumes, StorageClasses, CRDs y los logs de los pods de todos los namespaces. Los logs pueden contener secretos.
• Con KUBELATCH_REQUIRE_PSA=false, la comprobación de PSA se desactiva, y kubelatch lo avisa en la parte superior de «Permisos» y en «Avisos», la campana de la barra superior. Úsalo solo si otra cosa (OPA, Kyverno) impone lo mismo: sin PSA, quien crea pods puede crear uno privilegiado y hacerse con el nodo.

Conceder acceso de emergencia con cluster-admin¶

cluster-admin es la vía preferida para una intervención urgente cuando kubelatch funciona. Queda auditado: el plano de control registra quién lo concedió y a quién, y cada petición hecha con él queda en la auditoría.

1. En «Permisos», pulsa «Conceder permisos», elige a la persona en «Cuentas» y después el cluster y el nivel cluster-admin. El ámbito pasa a «todo el cluster (*)».
2. 8 h ya está seleccionado; elige «Fecha…» para una caducidad más corta.
3. Escribe el motivo en «Motivo», la incidencia en «Ticket» y pulsa «Conceder 1 permiso».
4. Revócalo en cuanto termine la intervención.

cluster-admin es siempre un permiso directo: un grupo no puede darlo (Grupos).

Leer un permiso¶

Todas las listas pintan un permiso con la misma línea: en la ficha de una cuenta o de un grupo, en la página de un cluster o de un rol, en «Mis clusters» de «Inicio» y en «Permisos». Cada lista quita lo que su página ya deja fijo, como la cuenta en la ficha de la cuenta, y mantiene el resto en este orden:

Cuando algo impide que un permiso cuente, una segunda línea debajo lo dice: «Sin efecto» o «Sin acceso a» y el cluster (Permisos sin efecto), un permiso que sobra (Solapamientos) o «Cuenta deshabilitada: el permiso no cuenta mientras siga así.». En el móvil la línea ocupa dos renglones: el rol y su caducidad, y debajo el resto.

En las listas de un administrador, el menú del final de la línea depende del permiso:

• Uno directo: «Ver detalle», «Peticiones», «Ampliar» y «Revocar». El de una cuenta deshabilitada no tiene «Ampliar».
• Uno que llega por un grupo, por ejemplo Backend: «Abrir Backend», «Ver detalle», «Peticiones» y «Sacar de Backend», que saca a la cuenta del grupo tras una confirmación que enumera todo lo que pierde.
• Uno que un conjunto pone en un cluster, en una lista por cluster: «Ver detalle», «Peticiones» y las tres opciones del permiso sobre el conjunto, más abajo.
• Uno caducado o revocado: «Ver detalle» y «Peticiones».

«Ver detalle» abre «Detalle del permiso»: el grupo de Kubernetes (en un rol nativo, «Grupos del cluster», uno por línea), «Entra como» mientras el permiso está en vigor (el nombre con el que la persona entra en el cluster, tal como lo rinde su plantilla de identidad, o por qué no se puede; un nombre que comparten otras cuentas lo dice, porque ninguna entra; un bot entra siempre como bot:<nombre>), el «Origen», el estado («Activo», «Caducado» o «Revocado el …»), el «Motivo», el «Ticket» y «Concedido»: quién y cuándo. En un permiso de un grupo, «Concedido» nombra al administrador cuyo cambio en el grupo lo creó.

Los permisos directos activos llevan casilla. Al marcar el primero aparece bajo la lista una barra con «Seleccionar todo (N)», cuántos llevas marcados, «Ampliar N» y «Revocar N» (Revocar varios permisos).

Un permiso sobre un conjunto¶

Un permiso sobre un conjunto se pinta distinto en cada tipo de lista:

• En las listas por cuenta («Lista» de «Permisos», «Por cuenta», la ficha de una cuenta y la de un grupo) es una línea y cuenta una vez. Las líneas forman una sección propia, «Sobre un conjunto», que va la primera en una lista con secciones; en una lista plana se ordenan por su final entre el resto. La línea dice el rol y el conjunto (viewer en staging); en «Dónde», el conjunto, el ámbito y «3 de 4 clusters»; en «Hasta», su final; y en «Por qué», «sigue al entorno» o «sigue a la etiqueta», y después el ticket y el motivo.
• En las listas por cluster («Por cluster», el mapa, la página de un cluster, la de un entorno y «Mis clusters» en «Inicio») cada cluster tiene su propia línea, y «Por qué» dice «vía staging», con el conjunto en mono, donde diría «directo» o el grupo. «Origen», en «Detalle del permiso», dice lo mismo.

Pulsa «Dónde» en la línea de un conjunto para desplegar una línea por cada cluster del conjunto: su final donde el cluster tiene el permiso, y «Sin efecto:» con el motivo donde no. Mientras kubelatch no ha decidido algunos clusters, «Sin efecto todavía en 1 cluster.» va bajo la línea.

La línea tiene un solo menú, que actúa sobre el permiso entero: «Ampliar el permiso sobre staging», «Volver a comprobar» y «Revocar el permiso sobre staging». La línea de una cuenta deshabilitada conserva solo «Revocar». Una línea sobre un conjunto no lleva casilla.

El motivo y el ticket¶

El campo que los formularios llamaban «Nota» ahora es «Motivo»; la API lo sigue llamando note. A su lado, «Ticket» enlaza el permiso con el tracker del equipo. kubelatch reconoce tres formas:

KUBELATCH_TICKET_URL es la plantilla del tracker, como https://acme.atlassian.net/browse/{key} (Configuración). Sin ella, una clave o un número se enseñan como texto. Cualquier otra cosa, de hasta 200 caracteres, se guarda tal cual y nunca es un enlace; solo lo son las URL https://. kubelatch no comprueba que el ticket exista en el tracker.

El ticket sale en la línea del permiso, en «Detalle del permiso», en «Mis clusters» de «Inicio» y en Actividad, junto a cada petición que el permiso dejó pasar (Actividad). Ampliar o revocar un permiso no lo vuelve a pedir.

Revocar un permiso¶

1. En «Permisos», busca el permiso: elige su cuenta en «Por cuenta» o su cluster en «Por cluster», pulsa la celda de la cuenta en el mapa o búscalo en «Lista». La ficha de la cuenta y la página del cluster también lo listan.
2. Abre el menú del final de su línea, elige «Revocar» y confirma.

La revocación reconcilia el cluster: el binding y el grupo desaparecen en segundos. Las credenciales de la persona siguen valiendo para el resto de sus permisos. Si se queda sin ningún permiso en un cluster, el proxy responde 403 … has no active permissions on cluster ….

Un permiso que viene de un grupo no tiene «Revocar»: cambia en su grupo, quitando al miembro («Sacar de Backend», en el menú de su línea, lo hace desde aquí) o revocando el permiso del grupo (Grupos). Por API, DELETE /api/grants/{id} sobre él responde 409 grant.derived, con el grupo en params.group_id.

Un permiso que un conjunto pone en un cluster tampoco tiene «Revocar» propio: revoca el permiso sobre el conjunto, desde el menú de su línea, o saca el cluster del conjunto. DELETE /api/grants/{id} sobre él responde 409 grant.set_derived, con el conjunto en params.selector y su id en params.set_grant_id.

Un permiso que caduca deja de contar en el proxy en ese mismo instante. Su binding lo retira la pasada periódica (cada 10 minutos) o un «Reconciliar» manual.

Revocar varios permisos¶

1. En «Permisos», abre «Lista» en «Activos» y acótala con la búsqueda, un chip o un enlace desde otra página; o elige una cuenta en «Por cuenta» o un cluster en «Por cluster», o abre el panel de una celda del mapa.
2. Marca lo que quieras revocar: la casilla de una línea, o «Seleccionar todo (N)» en la barra que aparece bajo la lista con la primera marca, que marca todo lo que enseña el filtro. Mayúsculas y un clic marcan todas las líneas entre la última que marcaste y esta.
3. Elige «Revocar N». La confirmación nombra las cuentas que pierden el acceso y los clusters que kubelatch reconcilia, enumera los permisos cluster a cluster y admite un motivo opcional, que queda en el registro de control.

Un lote es todo o nada, de hasta 500 permisos. Si uno no se puede quitar, no cambia nada: el aviso lo nombra, su fila dice por qué y las marcas se quedan para desmarcarlo y repetir. Un permiso que otro administrador revocó mientras tanto no es un error: el aviso lo cuenta como ya revocado.

Solo llevan casilla los permisos directos activos; uno que viene de un grupo se revoca en su grupo. La ficha de una cuenta y la página de un cluster o de un rol revocan varios de la misma forma. Cuando los permisos revocados comparten rol y cluster, y cubrían cada una de sus cuentas en cada uno de sus ámbitos, el aviso ofrece «Volver a conceder», que abre el formulario de conceder con esas cuentas, esos ámbitos y ese rol.

Cada permiso deja su propia fila grant.revoke, y el registro de control enseña el lote en una línea (El plano de control).

Ampliar permisos¶

Para ampliar un permiso, elige «Ampliar» en el menú de su fila. Para ampliar varios, márcalos como para revocar y elige «Ampliar N» en la barra. Después elige la nueva caducidad:

• «+7 d» o «+30 d» suma ese tiempo a la fecha de cada permiso. Un permiso sin fecha de fin no lo admite: elige una fecha.
• «Una fecha para todos» pone la misma fecha a todos; la lista marca «Acorta» en los que adelanta.
• «Nunca» quita la fecha de fin, y solo aparece cuando todos los roles lo permiten y ningún permiso de una persona está en un entorno con máximo.

En un entorno así, el permiso de una persona que la elección llevaría más allá del máximo sale marcado con «prod: 8 h como mucho», y la confirmación espera, con una línea que da la última fecha que puede recibir.

La confirmación enumera cada permiso con su caducidad antes y después y admite un motivo opcional, que queda en el registro de control. Un lote es todo o nada, de hasta 50 permisos, y rechaza el permiso de una cuenta deshabilitada. Un permiso privilegiado, como cluster-admin, mantiene sus 8 horas contadas desde que se concedió: para ir más allá, revócalo y vuelve a concederlo (Las reglas).

Cada permiso deja su propia fila grant.expiry, con la caducidad antes y después (El plano de control).

Un permiso sobre un conjunto se amplía entero, desde el menú de su línea, y la ampliación comprueba cada uno de sus clusters (Ampliar un permiso sobre un conjunto). Por API, PATCH /api/grants/{id} sobre lo que un conjunto puso en un cluster responde 409 grant.set_derived.

Dueños¶

En Pro, un administrador nombra a los «Dueños» de un entorno, un cluster o un namespace de un cluster: personas, o un grupo cuyos miembros cuentan mientras dura su pertenencia. Sin ser administradores, los dueños conceden, amplían y revocan los permisos de ese sitio:

Un dueño nunca se da acceso a sí mismo: concederse un permiso, o ampliar el suyo, responde que un dueño no puede darse acceso a sí mismo. Solo un administrador concede o amplía cluster-admin, un rol nativo, un permiso que el cluster hace privilegiado o el permiso de un bot; y solo un administrador acorta o revoca un permiso de cluster-admin o de un rol nativo. Un dueño acorta y revoca los demás permisos de su sitio, también los de un bot o un administrador. Las reglas del entorno se le aplican igual que a un administrador.

Los permisos sobre un conjunto, las cuentas, los roles, los clusters y los entornos siguen siendo de los administradores, y también nombrar dueños. Una escritura fuera del sitio responde que queda fuera de lo que gestionas. Cada cambio de un dueño deja su fila de siempre en el registro de control, con as: owner y el ámbito que se lo permitió (El plano de control). Sin Pro los dueños dejan de actuar, y sus filas se conservan.

Permisos sin efecto¶

Cuando un cluster da acceso privilegiado a un nombre, un permiso que da ese nombre durante más de 8 horas, o cualquier permiso de grupo que lo dé, incumple la regla de las 8 horas: la reconciliación deja fuera el nombre y todos los que entran al cluster con él se quedan sin acceso allí. Todas las listas marcan los dos lados, bajo la línea del permiso:

• «Sin efecto» en el permiso que incumple la regla, con el motivo, a cuántas personas deja sin acceso y «Ver por qué», que abre el problema en la página del cluster.
• «Sin acceso a» y el cluster en los demás permisos de esas personas allí, con el permiso que las deja fuera, enlazado.

«Verlos en Permisos», en la página del cluster, abre «Lista» solo con los permisos sin efecto de ese cluster («Solo los permisos sin efecto.», con «Mostrar todos» para volver). Márcalos y revócalos de una vez; un permiso que llega de un grupo se arregla en su grupo. En todas las vistas, el chip «N con problemas» enseña los dos lados a la vez. Estas marcas solo las ven los administradores.

Las vistas¶

«Permisos» enseña los permisos en vigor en cuatro vistas: «Por cluster», «Por cuenta», «Mapa» y «Lista». Con más de 6 clusters registrados, contando los que aún no están enrolados, se abre en «Por cluster»; con 6 o menos, en «Mapa». La dirección de la página guarda la vista que eliges, así que un enlace también la abre.

• «Por cluster» dice quién llega a un cluster y hasta cuándo.
• «Por cuenta» dice todo lo que tiene una cuenta, y se lo retira de una vez.
• «Mapa» cruza cuentas y clusters de un vistazo.
• «Lista» reúne todos los permisos, también los caducados y los revocados.

La cabecera cuenta lo que hay en la página antes de que la búsqueda y los chips lo acoten, por ejemplo «577 permisos de 66 cuentas en 42 clusters». Las cuentas sin ningún permiso en vigor están en «Usuarios».

Búsqueda y chips¶

La búsqueda encuentra logins, nombres, roles, clusters, namespaces, grupos, motivos y tickets. Cada chip deja lo que dice su nombre, y su cifra deja fuera las cuentas deshabilitadas:

Pulsa otra vez un chip para quitarlo. Mientras haya un chip o una búsqueda, una línea dice qué cumple, por ejemplo «57 permisos de 46 cuentas en 23 clusters cumplen el filtro.», con «Quitar filtros», que quita los chips y vacía la búsqueda sin cambiar la vista ni lo que tiene elegido; lo elegido que un filtro había ocultado vuelve. «Lista» no lleva esa línea: ya cuentan sus pestañas.

«Entorno» y «Etiqueta», tras los chips, dejan en todas las vistas solo los permisos sobre los clusters de un entorno o con una etiqueta (Filtrar Clusters y Permisos). «Quitar filtros» no los toca: elige «Todos los entornos» o «Todas las etiquetas» para quitarlos.

Lo que hace un filtro depende de la vista:

• «Por cluster» y «Por cuenta» listan solo los clusters o las cuentas con alguna coincidencia, cada uno con cuántas suma, y el detalle enseña solo las líneas que cumplen.
• «Mapa» quita los clusters sin coincidencias, también de la columna «el resto», y pone primero los que más tienen. Deja las filas con alguna celda que cumple y atenúa las celdas que no.
• «Lista» deja las líneas que cumplen. Pulsar un chip abre «Activos», que es lo que cuentan los chips.

Un permiso caduca pronto cuando le quedan 7 días o menos: su caducidad se pinta en ámbar, y en rojo con menos de 24 horas; los dos chips de caducidad llevan los mismos colores. La barra lateral marca «Permisos» con los mismos recuentos en todas las páginas: un número en rojo para los de menos de 24 horas y otro en ámbar para el resto de la semana. Pulsa un número para abrir «Permisos».

Por cluster¶

«Por cluster» lista los clusters a la izquierda y, a la derecha, los permisos del que eliges.

La lista dice cuántos clusters tiene y los ordena por «Riesgo», «A–Z» o «Cuentas». «Riesgo» pone primero los clusters en error y después los que tienen más permisos sin efecto, más que caducan hoy, más que caducan esta semana y más cluster-admin, en ese orden. «Cuentas» pone primero los que tienen más cuentas. Cada cluster enseña su proveedor, cuántas cuentas tienen permiso en él y como mucho dos píldoras: «en error», «1 sin efecto», «3 hoy» o, si no, «2 esta semana». Un cluster que aún no está enrolado dice «sin enrolar».

El detalle empieza por el cluster, una línea como «EKS · 29 cuentas · 39 permisos», «Ficha del cluster» y «Conceder en prod», que abre el formulario de conceder con el cluster puesto. Debajo van sus permisos como en la página del cluster: primero «Todo el cluster» y después cada namespace, con la caducidad más próxima delante, y cada línea con su menú y su casilla (Leer un permiso). Pulsa un login para abrir «Por cuenta» con esa cuenta elegida. Un cluster sin permisos dice «Nadie tiene permisos en prod.» y ofrece «Conceder en prod».

Con un filtro, el detalle acaba en «4 permisos más en prod no cumplen el filtro.» y «Mostrar todos»; «Ver solo los que cumplen» vuelve al filtro.

La lista es una sola parada del tabulador: las flechas arriba y abajo la recorren y van eligiendo a su paso, e Inicio y Fin saltan a los extremos. En el móvil la lista va arriba, y al tocar un cluster bajas a su detalle.

Por cuenta¶

«Por cuenta» hace lo mismo con las cuentas: a la izquierda las que tienen algún permiso en vigor y a la derecha todo lo que tiene la que eliges.

La lista las ordena por «Riesgo», «A–Z» o «Clusters». «Riesgo» pone primero las cuentas con más permisos sin efecto y después las que tienen más que caducan hoy y esta semana; «A–Z» deja los bots al final; «Clusters» pone primero las que llegan a más clusters. Cada cuenta enseña «7 clusters · 12 permisos» y como mucho dos píldoras: «1 sin efecto», «3 hoy» o, si no, «2 esta semana». Una cuenta deshabilitada dice «Deshabilitada»: sus permisos siguen ahí pero no cuentan, así que no llevan píldora.

El detalle empieza por la cuenta y su nombre, sus grupos como enlaces («Miembro de Backend y Seguridad»), una línea como «25 clusters · 38 permisos: 3 directos y 35 vía grupos» y sus acciones: «Ficha de alice», «Conceder a alice» (no en una cuenta deshabilitada) y «Retirar sus permisos…», cuando hay algo que retirar. Debajo van sus permisos por cluster, como en la ficha de la cuenta, y «Ver quién más llega», a la derecha de cada cluster, abre «Por cluster» con ese cluster elegido. Los filtros funcionan como en «Por cluster».

Una cuenta sin nada en vigor a la que llegas por un enlace desde su ficha, ⌘K o «Auditoría» sale igualmente, sin permisos y con «Conceder a alice». Un enlace que acota la página a un cluster, como la cifra «Cuentas» de «Clusters» (Enlaces desde otras páginas), limita «Por cuenta» a ese cluster, bajo «Solo en prod.» con «Ver todos sus clusters».

Retirar sus permisos¶

«Retirar sus permisos…» quita de una vez todo lo que tiene una cuenta: revoca sus permisos directos y la saca de sus grupos. La cuenta, sus credenciales y sus sesiones siguen: desde la siguiente petición no llega a ningún cluster. Para dar de baja a alguien, deshabilita su cuenta desde su ficha (Deshabilitar y habilitar).

1. En «Por cuenta», elige la cuenta y pulsa «Retirar sus permisos…».
2. La confirmación, «Retirar los permisos de alice», trae una casilla por paso, todas marcadas: «Revocar 3 permisos directos», con sus clusters, y «Sacar de Backend» por cada grupo, con lo que le da el grupo; los demás miembros no cambian. Desmarca lo que deba quedarse.
3. Si quieres, escribe un motivo: va en cada paso y queda en el registro de control. Pulsa «Retirar N permisos».

Los pasos van uno tras otro: primero los permisos directos, después cada permiso sobre un conjunto entero y por último cada grupo. El aviso dice lo hecho, por ejemplo «Retirados los permisos de alice: 3 revocados y fuera de Backend y Seguridad.». Si un paso falla, todo se para ahí: el aviso dice lo que sí se hizo y la alerta lo que falló. Lo hecho no se deshace, así que un fallo deja siempre menos acceso, nunca más. Un permiso o una pertenencia que terminó mientras tanto cuenta como hecho. Cada permiso revocado deja su fila grant.revoke, cada permiso sobre un conjunto su set.grant.revoke y cada grupo su group.member.remove, todos con el motivo, igual que si los quitaras uno a uno (El plano de control).

El mapa¶

«Mapa» enseña quién tiene qué y dónde: una fila por cuenta con algún permiso en vigor y una columna por cluster registrado, enrolado o no.

• Cada columna es un cluster: su id y cuántas cuentas tienen permiso en él, y después «· 3 hoy» o «· 2 esta semana» cuando algo caduca pronto allí, o «· 57 coinciden» con un filtro. Púlsala para abrir «Por cluster» con ese cluster elegido; la búsqueda y los chips se mantienen.
• Con «Por grupo», las filas se reparten en una franja por grupo, por nombre: el grupo como enlace, sus miembros y lo que da, por ejemplo «da developer en prod (shop, payments) y viewer en staging». Debajo van sus miembros, y quien está en dos grupos sale en los dos, la segunda vez con «también en Backend». «Sin grupo» y «Bots» van al final. «A–Z» quita las franjas y lista a todos por login, con los bots al final. La fila de una cuenta deshabilitada va atenuada y dice «Deshabilitada». Pulsa una cuenta para abrir «Por cuenta» con ella elegida.
• Cada celda resume una cuenta en un cluster: su rol más fuerte, con «+2» por sus permisos de otros roles allí; dónde tiene ese rol (un namespace, dos, «3 namespaces» o «todo el cluster»); su caducidad más próxima; y el problema, si lo hay: «Sin efecto», «Sin acceso a» y el cluster, o «1 redundante». Un punto quiere decir que no tiene acceso. El rol más fuerte es primero uno sensible, y después los de sistema en este orden: cluster-admin, admin, debugger, secrets-reader, developer, viewer.

El mapa es una sola parada del tabulador, que empieza en la primera celda con acceso: las flechas pasan de una celda a otra y llegan también a las cabeceras de columna, a las cuentas y a los enlaces de los grupos; Inicio y Fin van a los extremos de la fila (con Ctrl, del mapa), Re Pág y Av Pág saltan diez filas, e Intro o Espacio abre la celda. En el móvil cada cuenta es una tarjeta con una línea por cluster al que llega.

Columnas¶

El mapa dibuja las columnas de cluster que caben en el ancho de la página, nunca menos de dos, y las vuelve a ajustar cuando cambia el ancho de la ventana. Si alguna no cabe, una última columna, «+36 clusters» («el resto, por cuenta»), las resume para cada cuenta: en cuántos clusters tiene cada rol, contando el más fuerte de cada uno y con el rol más fuerte delante, por ejemplo «developer en 3 · viewer en 12». Con un filtro añade «2 clusters más coinciden». Un guion quiere decir que no tiene nada en el resto; una celda con algo abre «Por cuenta» con esa cuenta elegida.

«Columnas» elige qué clusters van primero:

• «Más riesgo», por defecto: primero los clusters en error y después los que tienen más permisos sin efecto, más que caducan hoy, más que caducan esta semana y más cluster-admin.
• «Más cuentas»: primero los clusters con más cuentas.
• «Elegidos…»: parte de las columnas que se ven y trae «Clusters» para elegirlas. Se ven todas las elegidas aunque no quepan, y entonces el mapa se desplaza de lado. Sin ninguna elegida, el mapa dice «Elige al menos un cluster.».

«Clusters» abre una lista con una búsqueda por id o proveedor, «Todos», «Ninguno», cuántos llevas elegidos («3 de 42») y «Solo» junto a cada cluster, que deja únicamente ese.

El panel de una celda¶

Pulsa una celda para abrir a la derecha los permisos de esa cuenta en ese cluster, por ejemplo «alice en prod» con «4 permisos: 2 directos y 2 vía Backend» («vía grupos» cuando los dan varios grupos). Cuando el mapa enseña un solo grupo, desde la ficha de ese grupo, el panel lista solo lo que da el grupo. Cada uno es una línea con su menú y su casilla (Leer un permiso), así que amplías, revocas o sacas de un grupo ahí mismo. «Conceder en prod» abre el formulario de conceder con la cuenta y el cluster puestos, y «Ficha de alice» abre la cuenta. Al cerrar el panel vuelves a la celda. La dirección de la página guarda el panel (?cell=), así que también lo abre un enlace.

La lista¶

«Lista» muestra cada permiso como una línea, primero la caducidad más cercana, en tres pestañas: «Activos», «Caducados» y «Revocados», cada una con su número. Mientras la búsqueda tiene texto, cada número dice cuántos coinciden del total (2 de 40). Un permiso revocado dice cuándo y quién lo revocó. Con más de 8 clusters, «Clusters» elige cuáles enseña la lista, como en el mapa.

El permiso de una cuenta deshabilitada sigue en «Activos», atenuado y con «Cuenta deshabilitada: el permiso no cuenta mientras siga así.» debajo. No se aplica en ningún sitio, así que los chips y la barra lateral lo dejan fuera.

Enlaces desde otras páginas¶

Otras páginas abren «Permisos» en una cuenta, en un cluster o con un filtro, en la vista que nombra el enlace o, si no nombra ninguna, en la que abre la página (Las vistas). Esa vista no cambia aunque filtres o cierres un panel. Una línea encima dice qué muestra un filtro, con su botón para quitarlo, por ejemplo «Solo lo que da Backend» con «Quitar filtro».

Inicio¶

El «Inicio» de quien administra es el parte del día: lo que te espera, lo que ha cambiado en las últimas 24 horas y cuánto queda expuesto, en una sola pantalla de portátil.

• La línea bajo el título dice cuántos clusters hay y cuántos están listos, cuántas cuentas, y cuándo fue la última reconciliación. «2 recomendaciones de la instalación» lleva a la lista de salud de «Edición» (La página de Edición), y «Nada pendiente» cierra la línea cuando no hay nada que hacer.
• «Poner en marcha kubelatch» enseña cuatro pasos que se marcan solos, hasta que hay un cluster enrolado y algún permiso activo.
• «Pendiente» tiene una línea por cada cosa que te espera, cada una con su salida: un cluster en error («Ver problemas»), los permisos que acaban hoy y quién se queda sin un cluster con ellos, la solicitud de un agente y las personas que piden entrar por el SSO («Revisar»), las credenciales de bots que caducan hoy y las invitaciones que caducan esta semana. Más de tres de un mismo tipo se pliegan en una línea, y a partir de seis, «y N más» enseña el resto. Si no hay nada pendiente, la tarjeta no sale.
• «Últimas 24 h» tiene las cinco últimas entradas del registro de control, cada una con quién la hizo, y «Plano de control» abre el registro entero (El plano de control). Debajo, «Accesos sensibles» cuenta los exec (y attach), las lecturas de Secrets y los port-forward de esas 24 horas, permitidos y denegados. Cada cifra abre «Auditoría» solo con esas peticiones, y al pasar el puntero por encima dice quién las hizo. En cuanto un entorno se marca como producción, la línea dice «Accesos sensibles en producción» y cuenta solo los clusters de esos entornos (sin ninguno marcado, cuenta todos); cada cifra abre entonces «Auditoría» con «Producción» puesto en «Entorno», así que sigue coincidiendo con la lista que abre. «Operativa» sigue contando todos los clusters.
• «Tendencias» tiene cuatro cifras de los últimos 30 días. «Operativa de los clusters», en su cabecera, abre la página Operativa, y cada cifra lleva a su parte de la página:
  • «Credenciales de corta vida»: qué parte de las cuentas entró solo con credenciales que caducan solas, con una fila para «Personas», otra para «Bots» y otra para «Agentes», cada una repartida en «Corta vida», «Larga duración» y «Sin uso» (Corta vida y larga duración). «N de larga duración activas» las abre en «Credenciales».
  • «Permisos que acaban solos»: qué parte de los permisos activos tiene fecha de fin y cuánto ha cambiado en 30 días, con enlaces a los que no caducan («sin caducidad») y a las cuentas «con cluster-admin».
  • «Peticiones, 7 días»: el total de los últimos siete días y la parte denegada, con una columna por día.
  • «Sin usar en 30 días»: los permisos activos cuya cuenta no ha hecho ninguna petición en su ámbito en 30 días, y las credenciales que nadie ha usado. «Revisar los N» los abre en «Lista» (Revocar varios permisos).

En Free salen las cuatro cifras, y las dos que necesitan más de 24 horas de auditoría dicen lo que añade Pro en lugar de un número: «Peticiones, 24 h» enseña las últimas 24 horas por horas, con «Con Pro: 14 días de historial», y «Sin usar en 30 días» dice «Con Pro: los permisos que nadie usa en 30 días». Si la retención de tu auditoría guarda menos de 30 días, «Sin usar en 30 días» dice que no puede medirlos.

Debajo de todo esto van tus propios accesos, como los ve cualquiera que trabaja con los clusters (Ver tus accesos). Si no tienes permisos ni credenciales propios, una línea dice que para administrar kubelatch no hacen falta, con «Concédete uno».

Solapamientos¶

Un permiso sobra cuando otro permiso activo de la misma cuenta, en el mismo cluster y ámbito, ya da todo lo que da él:

• el rol del otro es un rol de sistema que cubre el suyo: developer cubre viewer, admin cubre developer y viewer, cluster-admin cubre admin, developer y viewer (Qué nivel cubre a cuál);
• o el otro tiene el mismo rol y viene de un grupo o de un permiso sobre un conjunto, mientras que este es directo.

El permiso que sobra lleva una línea en ámbar bajo la suya, en todas las listas: «developer (directo) ya incluye viewer: este permiso sobra», o «developer vía Plataforma ya incluye viewer: este permiso sobra» cuando el que lo cubre viene del grupo Plataforma, o «developer vía staging ya incluye viewer: este permiso sobra» cuando viene de un permiso sobre staging. La línea se calcula sobre todos los permisos de la cuenta, así que una búsqueda o un chip que dejan fuera el que lo cubre no la esconden. En el mapa, la celda los cuenta: «1 redundante».

No se revoca nada solo. Revoca el permiso directo que sobra si ya no hace falta; uno de un grupo se cambia en su grupo. debugger y secrets-reader no cubren ningún otro rol: solo el mismo rol desde un grupo o desde un permiso sobre un conjunto los hace sobrar. Los roles personalizados nunca llevan la línea, porque un rol personalizado no dice qué cubre.

Añadir CRDs a un nivel¶

Un rol personalizado con una regla avanzada es la forma de conceder los recursos de un CRD solo a algunas personas. Para añadirlos en cambio a todos los que tienen un nivel: los niveles viewer, developer, debugger y secrets-reader son ClusterRoles agregados. Para que incluyan los recursos de un CRD, crea en el cluster un ClusterRole pequeño con la etiqueta kubelatch.io/aggregate-to-<nivel>: "true":

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: certificates-viewer
  labels:
    kubelatch.io/aggregate-to-viewer: "true"
rules:
  - apiGroups: ["cert-manager.io"]
    resources: ["certificates", "issuers"]
    verbs: ["get", "list", "watch"]

Lo que agregas a viewer llega también a developer, que lo contiene. admin y cluster-admin son los roles de Kubernetes y siguen sus propias reglas de agregación.

Comprobar qué puede hacer alguien¶

kubelatch no admite kubectl --as: el proxy rechaza con 400 cualquier cabecera Impersonate-* del cliente. Para comprobar qué puede hacer un sujeto, usa el acceso nativo de administrador del cluster con su usuario y su grupo:

kubectl --kubeconfig <kubeconfig-admin-del-cluster> auth can-i create pods --subresource=exec -n apps \
  --as user:alice --as-group kubelatch:ns:apps:debugger

Los bots aparecen como bot:<nombre>.