Entornos y etiquetas¶

Un entorno reúne clusters bajo un nombre, como prod, pre o staging, dice si son de producción y puede llevar reglas para los permisos de las personas. Una etiqueta es un par clave: valor de un cluster, como equipo: pagos o region: eu, igual que en Kubernetes. Un cluster está en un entorno como mucho y lleva hasta 20 etiquetas. Aquí ves cómo crear entornos, meter clusters en ellos, ponerles reglas, etiquetar los clusters, usar las dos cosas para agrupar el diagrama y filtrar «Clusters» y «Permisos», y conceder un permiso en todos los clusters de un entorno o con una etiqueta.

La marca de producción no cambia ningún permiso, y una etiqueta tampoco por sí sola. Las reglas de un entorno, en Pro, limitan lo que duran los permisos de las personas en sus clusters: guardar una regla más estricta, o meter un cluster en un entorno con máximo, recorta lo que lo supera, después de una confirmación que lo enumera. Un permiso sobre un conjunto, también de Pro, sigue a un entorno o a una etiqueta: el cluster que entra en él recibe el permiso, y el que sale lo pierde.

Antes de empezar¶

• Eres administrador de kubelatch. Los entornos, las etiquetas y sus filtros son solo para administradores.
• Los clusters están registrados (Registrar un cluster). Un cluster sin enrolar también admite entorno y etiquetas.

La lista de Entornos¶

«Entornos», bajo «Clusters» en la barra lateral, lista todos los entornos. Su primera línea los cuenta, con los clusters que tienen y los que no están en ninguno: «4 entornos para 12 clusters. 2 clusters no tienen entorno.» Cada fila lleva el id del entorno, «Producción» si está marcado, cuántos clusters tiene y los tres primeros, seguidos de «y N más», y en «Reglas», sus reglas en una línea («Máximo 8 h · por defecto 2 h», o «Sin reglas»). Primero van los marcados como producción y después el resto, por id. La última fila, «Sin entorno», cuenta los clusters que no están en ninguno.

El menú de la fila tiene «Abrir», «Ver en Permisos» (los permisos sobre sus clusters) y «Eliminar».

Crear un entorno¶

1. En «Entornos», pulsa «Nuevo entorno». El formulario se abre en un panel a la derecha; la paleta de comandos (⌘K) también tiene «Nuevo entorno».
2. Rellena «Id», su nombre, como prod, pre o staging: de 1 a 63 letras minúsculas, dígitos o guiones, empezando por una letra o un dígito.
3. Marca «Producción» si sus clusters son de producción.
4. Pulsa «Crear». Llegas a su página con el aviso «Entorno prod creado.»

El id es el nombre del entorno y no cambia nunca. Para renombrar uno, crea el nuevo, pasa a él sus clusters y elimina el viejo. Un id que ya tiene otro entorno se rechaza: «ya existe un entorno con ese id».

La página de un entorno¶

Pulsa un entorno para abrir su página, /admin/environments/<id>. La cabecera lleva el id, «Producción» si está marcado, cuántos clusters tiene («3 clusters.») y, con una duración máxima, lo que garantiza («Ningún permiso de una persona dura más de 8 h.»), y después «Editar» y «Eliminar entorno». Debajo van tres tarjetas:

• «Reglas» enseña su duración máxima y su caducidad por defecto, cada una con lo que hace, o «Sin reglas» (Reglas).
• «Clusters de prod» lista sus clusters, cada uno con la píldora de su nivel («Listo», «Aviso»…) y un menú con «Abrir» y «Quitar de prod».
• «Permisos aquí» cuenta los permisos en vigor en sus clusters y las personas que los tienen, sin contar las cuentas deshabilitadas: «12 permisos en vigor en sus clusters; 5 personas tienen al menos uno.» Los permisos de un bot cuentan como permisos, pero el bot no cuenta como persona. «Ver en Permisos» abre «Permisos» con «Entorno» puesto en él.

Meter clusters en un entorno¶

Un cluster está en un entorno como mucho. Hay dos formas de meterlo en uno:

• Desde el entorno: en su página, pulsa «Añadir un cluster», elige el «Cluster» y pulsa «Añadir a prod». Cada cluster de la lista dice dónde está ahora («en staging», «sin entorno»); el que está en otro entorno pasa a este, y el panel lo avisa antes de añadirlo: «eu-2 deja staging: un cluster está en un entorno como mucho.» Sus etiquetas se quedan como están.
• Desde el cluster: «Entorno y etiquetas», en su página (más abajo).

Cuando el entorno tiene una duración máxima y el cluster tiene permisos de personas que la superan, o cuando el cambio quita al cluster un permiso sobre un conjunto o le da uno, las dos formas preguntan antes con la confirmación del recorte; si no hay nada que recortar ni mover, guardan al momento.

«Quitar de prod», en el menú de un cluster en la página del entorno, lo deja sin entorno: un cluster sin entorno no tiene reglas, así que no se recorta nada y sus permisos conservan su caducidad. Sus etiquetas se quedan. Guarda al momento, salvo que mueva un permiso sobre un conjunto: uno que sigue a prod deja de llegar al cluster, y uno sobre una etiqueta que el máximo de prod rechazaba puede empezar a llegar. La confirmación lo dice antes.

Marcar un entorno como producción¶

«Editar», en la página del entorno, abre un panel con «Producción». Marca o desmarca la casilla y pulsa «Guardar cambios»; el aviso dice «prod está marcado ahora como producción.» o «prod ya no está marcado como producción.»

La marca cambia lo que enseña kubelatch, nunca quién puede hacer qué:

• «Inicio»: en cuanto hay un entorno marcado, «Accesos sensibles» pasa a «Accesos sensibles en producción» y cuenta solo los clusters de los entornos marcados; sin ninguno marcado, cuenta todos (Inicio).
• «Auditoría»: «Entorno» ofrece «Producción», todos los entornos marcados a la vez (Buscar peticiones a los clusters).
• La píldora «Producción» acompaña al entorno allí donde se nombra, y la página de un cluster la lleva en su cabecera (prod · Producción). Los entornos marcados van primero en todas las listas.

Reglas (Pro)¶

Un entorno puede llevar dos reglas, las dos opcionales:

Una regla dura de 1 hora a 365 días. La regla de las 8 horas del acceso privilegiado sigue valiendo además de estas.

Las reglas valen para los permisos propios de las personas y para los permisos de grupo, sean quienes sean sus miembros. Nunca valen para los permisos propios de un bot: un bot conserva sus 30 días por defecto y puede no tener fecha de fin, así que un bot que necesite acceso permanente a prod lo recibe con un permiso directo. Un agente de IA que actúa por una persona nunca dura más que el permiso de esa persona.

Cambiar las reglas¶

1. En la página del entorno, pulsa «Cambiar reglas» en la tarjeta «Reglas». Se abre el panel «Reglas de prod».
2. En «Duración máxima», elige «Sin máximo», 8 h, 1 día, 7 días, 30 días, 90 días u «Otra», que pide una cantidad en «horas» o en «días».
3. En «Caducidad por defecto», elige «Sin valor propio» o una duración de la misma forma. Las que pasan de la duración máxima salen desactivadas, con «Pasa de la duración máxima.»
4. Pulsa «Guardar». Si las reglas nuevas no recortan nada, se guardan al momento y el aviso dice «Reglas de prod guardadas.»

A partir de ahí, las reglas se ven en una línea en la lista de «Entornos», en cada caja del diagrama agrupado por «Entorno» y junto a cada entorno en el panel «Entorno y etiquetas» de un cluster: «Máximo 8 h · por defecto 2 h». Para quitar una regla, elige «Sin máximo» o «Sin valor propio».

El recorte¶

Un máximo vale para los permisos que ya existen, no solo para los nuevos. Guardar un máximo más corto, o uno donde no lo había, recorta hasta ahora más el máximo cada permiso activo de una persona o de un grupo en los clusters del entorno que termina después o que no termina nunca. Meter un cluster en un entorno con máximo hace lo mismo en ese cluster. Nunca se alarga nada, y los permisos propios de los bots no cambian. Los miembros de un grupo siguen al permiso del grupo.

Antes de guardar, una confirmación enumera lo que se va a recortar. Su título dice el cambio («Cambiar las reglas de prod», «Mover eu-2 a prod» o «Guardar el entorno y las etiquetas de eu-2») y su texto lo cuenta: «Recorta 9 permisos de 6 personas hasta el 6 nov, 18:00. Nada se alarga y los bots no cambian.» Un permiso de grupo cuenta una vez, y sus miembros cuentan entre las personas. Debajo van los cinco primeros, cada uno con quién lo tiene (la cuenta o el grupo), su rol, dónde, cuándo termina ahora y cuándo terminará; «Ver los 9» despliega el resto. La línea de una cuenta deshabilitada va atenuada, con «Cuenta deshabilitada». «Guardar y recortar 9» guarda; «Cancelar» no envía nada.

La confirmación enseña lo que kubelatch encontró al pulsar «Guardar»; el guardado actúa sobre lo que hay en ese momento, y el aviso dice lo que de verdad recortó: «Reglas de prod guardadas. 9 permisos recortados hasta el 6 nov, 18:00.» kubelatch reconcilia cada cluster que ha tocado. Cada permiso recortado deja su fila en el registro de control, y el registro enseña el guardado y sus recortes en una sola línea (El plano de control).

Relajar una regla, con un máximo más largo o sin ninguno, no alarga nada: los permisos conservan el final que tienen.

Un cambio que además mueve permisos sobre un conjunto los enumera en la misma confirmación.

Conceder con reglas¶

En un cluster cuyo entorno tiene reglas, los formularios que conceden y amplían permisos a personas y a grupos las siguen (Conceder un permiso, Ampliar permisos): proponen la caducidad por defecto y no ofrecen ni «Nunca» ni nada que pase del máximo. La API rechaza lo mismo con 400 grant.environment_max (Errores).

Free y la clave caducada¶

Poner o cambiar una regla pide Pro. En Free, la tarjeta «Reglas» lleva «Pro» y «Ver Pro», que abre «Edición», y enseña las reglas guardadas sin «Cambiar reglas».

Las reglas guardadas se siguen aplicando en Free y con la clave caducada: siguen rechazando, proponiendo y recortando. Quitarlas no pide Pro nunca: «Quitar las reglas», en la tarjeta, pregunta antes («Quitar las reglas de prod»: «Los permisos que ya existen no cambian; los nuevos dejan de tener máximo y reciben 30 días por defecto. Volver a ponerlas pide Pro.»), y el aviso dice «Reglas de prod quitadas.»

Eliminar un entorno¶

«Eliminar entorno», en su página, o «Eliminar», en el menú de su fila en «Entornos», pregunta antes y dice qué cambia: «Sus 3 clusters se quedan sin entorno; sus etiquetas y sus permisos no cambian.» Pulsa «Eliminar». Los clusters siguen ahí, sin entorno y con sus etiquetas.

Si hay permisos sobre un conjunto que siguen al entorno, la eliminación los revoca, y la confirmación los enumera antes, junto con lo que ganan sus clusters: un cluster fuera del entorno está fuera de sus reglas, así que un permiso sobre una etiqueta que el máximo rechazaba llega ahora a él.

Etiquetas¶

Una etiqueta es un par clave: valor, como equipo: pagos, region: eu o cliente: acme. Sirven para lo que el entorno no dice: el equipo, la región, el cliente. Un permiso sobre un conjunto puede seguir a una. Las etiquetas siguen el formato de las de Kubernetes, en minúsculas y sin prefijo:

Un cluster lleva hasta 20 etiquetas, con un solo valor por clave: un cluster es de un equipo y de una región. Las claves environment y entorno están reservadas, porque el entorno tiene su propio campo.

El entorno y las etiquetas de un cluster¶

La cabecera de la página de un cluster enseña su entorno junto a la píldora de su nivel, prod · Producción si está marcado como producción o solo el id si no, y debajo sus etiquetas (equipo: pagos, region: eu) y «Entorno y etiquetas». Ese botón abre un panel:

1. En «Entorno», elige uno, o «Sin entorno». Los marcados como producción lo dicen, y cada uno enseña sus reglas (prod · Producción · Máximo 8 h · por defecto 2 h). Si todavía no hay ningún entorno, el panel dice «Todavía no hay entornos: créalos en Entornos.»
2. En «Etiquetas», cada etiqueta es una fila con «Clave» y «Valor». «Añadir etiqueta» añade una fila, y la × del final la quita. Cada fila dice lo que está mal mientras escribes: una clave o un valor que no tienen el formato, una clave reservada («entorno está reservada: el entorno tiene su propio campo.») o una clave que ya tiene otra fila («Ya hay otra etiqueta equipo: una sola por clave.»).
3. Pulsa «Guardar». Si el entorno elegido tiene un máximo que superan algunos permisos del cluster, o el cambio mueve permisos sobre un conjunto, antes llega la confirmación del recorte. El aviso dice «Entorno y etiquetas de prod-eu guardados.», y lo que se recortó, si se recortó algo.

«Guardar» sustituye a la vez el entorno y todas las etiquetas, y espera a que algo cambie («Todavía no hay nada que guardar.»). Si otra persona cambió el entorno o las etiquetas del cluster después de abrir el panel, «Guardar» no escribe nada y lo dice, y el panel vuelve a empezar desde lo que el cluster tiene ahora; «Quitar de prod» y «Añadir un cluster» hacen lo mismo con lo que enseña su página. Cada vez que guardas queda en el registro de control una fila cluster.placement, con el entorno y las etiquetas de antes y de después y cuántos permisos recortó, aunque no haya cambiado nada (El plano de control).

Permisos sobre un conjunto (Pro)¶

Un permiso sobre un conjunto da a una persona, a un bot o a un grupo un rol en todos los clusters de un entorno, como staging, o en todos los que llevan una etiqueta, como equipo: pagos. El permiso sigue al conjunto: el cluster que entra lo recibe, y el que sale lo pierde. viewer en todo staging es un solo permiso, y el cluster de staging que registres el mes que viene queda cubierto desde que lo metes ahí.

El conjunto es un entorno o una etiqueta, nunca una combinación, y cluster-admin no se concede nunca sobre un conjunto: es personal y por cluster. En cada cluster del conjunto, el permiso es un permiso en vigor como cualquier otro: el proxy, el reconciliador, la CLI, los agentes de IA y los avisos de caducidad lo leen igual que uno directo.

Conceder un permiso sobre un conjunto¶

1. En «Permisos», pulsa «Conceder permisos» (Conceder un permiso). Para un grupo, pulsa «Añadir permisos» en su ficha (Añadir permisos del grupo).
2. En «Dónde», elige «Un entorno» o «Una etiqueta». «Clusters concretos» es el formulario de siempre. En Free, las dos opciones llevan «Pro» y «Ver Pro».
3. Elige el «Entorno», o la «Clave» y el «Valor» de la etiqueta. Una línea dice qué clusters entran hoy («Entran hoy: stg-a, stg-b.», o «Hoy no entra ningún cluster.») y que el permiso sigue al conjunto.
4. Elige los ámbitos: todo el cluster (*), cuando el rol lo admite, o namespaces, que escribes uno a uno en «Namespace» y añades con «Añadir», porque los clusters de un conjunto no comparten lista de ellos. Un namespace protegido o un nombre que no tiene el formato se rechaza mientras escribes.
5. Elige el rol, «Hasta cuándo» y la «Nota».
6. Mira la vista previa antes de conceder. Dice «Llega a 3 de 4 clusters.» y, por cada cluster al que no llega, «No llega a prod-eu:» con el motivo.
7. Pulsa «Conceder N permisos». El aviso dice «2 permisos concedidos sobre staging.»

El resumen cuenta un permiso por cuenta y ámbito, 50 como mucho de una vez, todo o nada: «2 permisos que siguen a staging: viewer en todo el cluster de los clusters de staging (hoy 4) a alice, bob, hasta el 11 nov».

La caducidad sigue las reglas del entorno. En un entorno con duración máxima, el formulario propone la caducidad por defecto y no ofrece nada más allá del máximo para una persona o un grupo, igual que con un permiso directo. En una etiqueta, cada cluster tiene su propio entorno: donde su máximo es más corto que la caducidad del permiso, el permiso no llega a ese cluster.

A qué clusters llega¶

Cada cluster del conjunto somete el permiso a las comprobaciones que pasaría uno concedido a mano allí (Las reglas): el namespace existe y exige el nivel de Pod Security que pide el rol, un rol personalizado encuentra el bootstrap que necesita, el nombre de un rol nativo no choca con otro y las reglas del entorno del cluster admiten la caducidad. El cluster que no pasa una no recibe nada del conjunto, y la línea del permiso dice «Sin efecto» allí, con el motivo; en el resto de clusters el permiso vale. Un cluster al que kubelatch no puede preguntar tampoco recibe nada. Quitar no espera nunca a un cluster: el que sale del conjunto pierde el permiso aunque no responda.

Cuándo decide kubelatch otra vez¶

kubelatch vuelve a decidir los clusters de un conjunto cuando:

• el permiso se concede, se amplía o se revoca (todos sus clusters);
• se guarda el entorno o las etiquetas de un cluster (ese cluster);
• se crea, se cambia o se elimina un entorno (sus clusters);
• un cluster se vuelve a enrolar, recibe tokens nuevos o cambia su plantilla de identidad (ese cluster).

Hay dos tipos de rechazo:

Un rechazo de regla espera porque reintentarlo con el reloj dejaría que un permiso de 7 días rechazado en prod entrase por sí mismo en sus últimas 8 horas, sin que nadie lo decidiera.

Volver a comprobar¶

Ampliar los clusters de un rol personalizado, o que un cluster pase al bootstrap v2, quita la causa de un rechazo de regla, pero no es un momento de decisión: nadie habría visto antes el acceso que da. «Volver a comprobar», en el menú de la línea, lo hace. Enseña lo que ganaría el permiso, «Volver a comprobar y dar 2» con los clusters, y lo aplica al confirmar. Si no cambia nada, dice «Nada nuevo: los motivos siguen.» y no envía nada. Después de comprobar, el aviso dice «Permiso de «alice» sobre staging: llega a 2 clusters más.» Funciona en todas las ediciones.

Ampliar un permiso sobre un conjunto¶

«Ampliar el permiso sobre staging», en el menú de la línea, mueve el final del permiso y el de lo que pone en cada cluster. Pide Pro: en Free, la opción lleva «Pro» y «Ver Pro».

Se aplican las reglas de cada cluster. Donde el entorno de un cluster tiene un máximo que la fecha nueva supera, el permiso deja de llegar a él, y la confirmación lo enumera antes («Deja de llegar a prod-eu:» con el motivo). Una ampliación no es nunca todo o nada: un cluster al que kubelatch no puede preguntar conserva su fecha («prod-eu no se pudo comprobar: conserva su fecha.») y kubelatch lo reintenta solo, hasta que el cluster recibe la fecha nueva o el permiso lo deja. En un entorno con máximo, el permiso de una persona o de un grupo no puede pasar de él (400 grant.environment_max).

Revocar un permiso sobre un conjunto¶

«Revocar el permiso sobre staging», en el menú de la línea, pregunta antes: «Revocar el permiso de «alice» sobre staging: deja de llegar a 3 clusters.» Revoca el permiso y lo que puso en cada cluster, de una vez, en cualquier edición.

Lo que un conjunto pone en un cluster no tiene «Revocar» propio: DELETE /api/grants/{id} sobre ello responde 409 grant.set_derived. Para quitarlo de un cluster, saca el cluster del conjunto.

Cuentas deshabilitadas¶

No se puede conceder un permiso sobre un conjunto a una cuenta deshabilitada (409 account.disabled). Si la cuenta se deshabilita después, lo que el conjunto puso en sus clusters se queda y no cuenta, igual que sus permisos directos; al habilitarla vuelve sin tocar nada. La línea de una cuenta deshabilitada conserva solo «Revocar»: no se puede ampliar ni volver a comprobar hasta que la cuenta se habilita.

Cuando desaparece algo de lo que depende el conjunto¶

• Un entorno que se elimina: los permisos sobre él se revocan (Eliminar un entorno).
• Un grupo que se elimina: los permisos sobre un conjunto que tiene se revocan con él, y sus miembros pierden lo que esos permisos les daban.
• Un rol personalizado que se elimina: los permisos sobre un conjunto que lo nombran se revocan junto con los demás que revoca la eliminación.
• Un rol personalizado que se edita: a diferencia de los permisos directos y de grupo, los permisos sobre un conjunto no bloquean nunca la edición. Donde la edición deja al rol sin poder usarse en un cluster del conjunto, porque el cluster sale de «Solo algunos…», se apaga todo el cluster o pasa a exigirse Pod Security, el permiso deja de llegar a ese cluster como un rechazo de regla y sigue valiendo en los demás. La confirmación de la edición lo enumera: «Dejan de llegar a prod-eu: 2 permisos sobre equipo: pagos.» (Editar un rol).
• El último cluster con una etiqueta la pierde: los permisos sobre esa etiqueta se quedan, sin llegar a ningún cluster, y llegan al primer cluster que vuelva a llevarla.

Cuando un cluster se mueve o una regla cambia¶

Cambiar el entorno o las etiquetas de un cluster lo mete y lo saca de conjuntos: recibe los permisos de los conjuntos a los que entra y pierde los de los que deja. Relajar una regla puede traer permisos sobre una etiqueta que su máximo rechazaba. En los dos casos se pregunta antes, con la confirmación del recorte, que enumera, después de lo que recorta, una línea por cada cluster que deja de recibir un permiso («Deja de llegar a prod-eu: el permiso de «alice» sobre equipo: pagos», seguido de la frase del motivo cuando lo causa una regla) y por cada uno que empieza a recibirlo («Llega a prod-eu: el permiso de «alice» sobre equipo: pagos»). Con un grupo dice «el permiso del grupo «pagos» sobre …». Van primero los cinco primeros de cada tipo, y «Ver los N» enseña el resto. Un permiso sobre un conjunto que el recorte acorta se lee como los demás, con «vía prod» al final. Si el cambio no recorta nada y solo mueve permisos sobre un conjunto, el botón dice «Guardar». Después de guardar, el aviso añade «N permisos sobre un conjunto cambian.», a partir de lo que hizo el guardado.

Cómo cuentan las listas¶

Un permiso sobre un conjunto es un permiso para el administrador que lo concede y uno en cada cluster para las personas que lo tienen, así que cada lista lo cuenta según lo que lista:

• Donde una lista va por cuenta, es una línea y cuenta una vez: la «Lista» de «Permisos», «Por cuenta», sus cifras y sus chips, la ficha de una cuenta y las marcas de la barra lateral. La línea enseña el rol y el conjunto, el ámbito, «3 de 4 clusters», «sigue al entorno» o «sigue a la etiqueta», su final y un menú. Un botón despliega una línea por cluster: su final donde tiene el permiso, y «Sin efecto:» con el motivo donde no (Leer un permiso).
• Donde una lista va por cluster, cada cluster cuenta el suyo y dice «vía staging»: «Por cluster», el mapa, la página de un cluster, la de un entorno, «Mis clusters» en «Inicio» y la confirmación del recorte.

Una línea con un rechazo temporal cuenta una vez en «Solo los permisos sin efecto.» y en los «N permisos sin efecto» que «Inicio» enseña para un cluster en error. Un rechazo de regla es deliberado (prod no admite más de 8 h), así que se lee en la línea desplegada y no cuenta como pendiente.

En Free y con la clave caducada¶

Conceder y ampliar un permiso sobre un conjunto piden Pro. En Free, «Un entorno» y «Una etiqueta», en «Dónde», llevan «Pro» y «Ver Pro», y «Ampliar» también. Lo que ya está concedido sigue funcionando en Free y con la clave caducada: los permisos siguen a sus conjuntos, se comprueban y se reintentan, y no se borra nada. Revocar, «Volver a comprobar» y eliminar un entorno, un grupo o un rol funcionan en todas las ediciones, porque ninguno da más acceso del que había.

Agrupar y filtrar¶

Agrupar el diagrama¶

En «Clusters», «Agrupar por», junto a las pestañas mientras está abierto el «Diagrama», elige las cajas del diagrama:

• «Proveedor»: una caja por proveedor, como cuenta El diagrama.
• «Entorno»: una caja por entorno, primero los marcados como producción, con «Producción», y después por id. «Sin entorno», con el borde discontinuo, va al final.
• Una clave de etiqueta, como equipo: una caja por valor, ordenadas por valor, y al final «Sin equipo», también con el borde discontinuo.

El diagrama abre agrupado por «Entorno» en cuanto algún cluster tiene uno, y por «Proveedor» si no. Un cluster sin enrolar va en la caja de su entorno o de su etiqueta. La elección se queda en la dirección (?by=environment, ?by=label:equipo); una clave que ya no lleva ningún cluster abre la agrupación por defecto.

Filtrar Clusters y Permisos¶

«Entorno» y «Etiqueta» dejan los clusters de un entorno, o los que tienen una etiqueta. Están junto a las pestañas en «Clusters» y tras los chips en «Permisos», y cada uno aparece en cuanto hay algo que elegir: «Todos los entornos» y cada entorno, «Todas las etiquetas» y cada clave: valor en uso. Los dos a la vez dejan los clusters que cumplen los dos. Se quedan en la dirección (?environment=prod, ?label=equipo:pagos), así que un enlace también los abre.

• En «Clusters» estrechan el diagrama y la «Lista», y los chips de la «Lista» cuentan dentro de lo que dejan.
• En «Permisos», todas las vistas se quedan solo con los permisos sobre esos clusters.

Una vista que se queda sin clusters dice «Ningún cluster coincide.» con «Limpiar», que quita los filtros.

Por API¶

Todo lo anterior existe en la API JSON: /api/environments, PUT /api/clusters/{id}/placement, GET /api/cluster-labels y, para los permisos sobre un conjunto, /api/cluster-set-grants. POST /api/environments/{id}/preview y POST /api/clusters/{id}/placement/preview dicen lo que recortaría un cambio, sin escribir nada. Las rutas están en API HTTP y permisos sobre un conjunto, y los errores en Errores y Permisos sobre un conjunto.