Gestionar roles¶

Un rol personalizado es un conjunto de permisos que compones con capacidades y, si hace falta, reglas avanzadas, y que después concedes como cualquier rol de sistema. Aquí ves cómo crearlo, duplicarlo, editarlo, eliminarlo y concederlo en «Roles». Qué puede llevar un rol, qué rechaza kubelatch y por qué está en Roles.

«Roles» está en la barra lateral, junto a «Permisos», solo para administradores.

Antes de empezar¶

• El rol de administrador en kubelatch.
• Para conceder un rol personalizado en un cluster, el cluster tiene el manifiesto de bootstrap actual. Un cluster registrado antes de que existieran los roles personalizados dice «Bootstrap v1: en este cluster no se pueden conceder roles personalizados.» en la tarjeta «Enrolamiento y salud» de su página en «Clusters»: actualiza su bootstrap antes. El rol lo puedes crear antes de eso.

Los roles personalizados son una función Pro: en Free están disponibles los seis roles de sistema y «Roles» lo indica. Una clave caducada o retirada mantiene los roles personalizados existentes; se pueden borrar, no crear ni editar. «Roles» lo indica mientras exista alguno. Ver Ediciones y licencia.

La página Roles¶

La tabla lista todos los roles, con los segmentos «Todos», «Sistema» y «Personalizados»:

El menú de acciones al final de cada fila tiene «Abrir», «Duplicar» (todos menos admin y cluster-admin) y, en los roles personalizados, «Editar» y «Eliminar». «Abrir» muestra el rol como una página: sus cifras, «Qué concede», «Dónde se aplica» y su resumen con el YAML, con «Duplicar», «Editar» y «Eliminar» en la cabecera. La paleta de órdenes (⌘K) tiene también «Nuevo rol» y cada rol por su nombre.

Crear un rol¶

1. En «Roles», pulsa «Nuevo rol». El constructor se abre como una página: a la izquierda, lo que compones, en el orden de las decisiones; a la derecha, en una pantalla ancha, lo que concede el rol en las pestañas «Resumen» y «YAML». En un móvil el resumen es una barra al pie de la página con el riesgo, «N recursos · M problemas» y «Resumen», que lo abre en un panel.

2. En «Rol», elige desde dónde empezar en «Empezar desde»: «En blanco», uno de viewer, developer, debugger y secrets-reader, o uno de tus roles personalizados. El chip copia las capacidades, las reglas y el ámbito de ese rol, y una línea bajo los chips nombra el punto de partida; una copia de viewer o de developer es una aproximación (Duplicar un rol). Si ya habías compuesto algo, el constructor pregunta antes de reemplazarlo. Después rellena:

   Campo	Qué poner
   «Nombre»	Lo que se leerá en las listas, hasta 80 caracteres.
   «Identificador»	Se muestra bajo el nombre y se deriva de él: de 2 a 39 minúsculas, dígitos y guiones. Pulsa «Cambiar» para escribir el tuyo. No cambia una vez creado el rol, y no se vuelve a usar nunca.
   «Descripción»	Una línea sobre para qué sirve el rol. Quien lo tiene la ve en su «Inicio».

3. En «Dónde se aplica», elige «Namespaces» (se concede en un namespace cada vez; todas las capacidades están disponibles) o «Namespaces y todo el cluster» (también se puede conceder con ámbito *; el rol solo lee, nunca Secrets, y alcanza también kube-system y kubelatch-system: por qué). Decídelo antes: fija qué capacidades están disponibles. En «Clusters», deja «Todos los clusters» o elige «Solo algunos…» y márcalos.

4. En «Capacidades», marca lo que necesita el rol, dominio a dominio. «Buscar capacidades» filtra por nombre. Lo que el ámbito descarta se pliega en una línea por dominio: con «Namespaces», las capacidades de todo el cluster, con «Cambiar» para cambiar el ámbito; con todo el cluster, las capacidades que escriben o leen Secrets. Una capacidad marcada que deja de caber tras cambiar el ámbito sigue visible y señalada, y una línea arriba ofrece apagarlas todas de una vez. Marcar una capacidad de escritura sin la de lectura que presupone («Escribir ConfigMaps» sin «Leer ConfigMaps») muestra una nota: kubectl edit y kubectl apply necesitan get. Su botón añade la lectura; el rol se guarda igual.
5. En «Reglas avanzadas», solo para lo que ninguna capacidad cubre, pulsa «Añadir regla». Cada regla tiene un «Grupo de la API» (escribe uno, o elige «Grupo core» para los Pods, los ConfigMaps y el resto del núcleo), «Recursos» (escribe cada uno y pulsa Intro), «Verbos» (pulsa los chips, o «Lectura» y «Escritura» para los conjuntos habituales) y, si quieres, «Nombres (opcional)». «Sugerir desde el cluster» lee la API de un cluster listo y ofrece sus grupos, recursos y verbos en esos campos; un verbo que el cluster no sirve para los recursos elegidos se dibuja a trazos. Sin un cluster listo, escribe los grupos y los recursos a mano.
6. Lee el resumen, que es la lectura que hace kubelatch del borrador: qué corregir, «Qué concede» en palabras, «Mira dos veces», «Requisitos», la tabla de recursos con «Leer», «Crear», «Actualizar» y «Eliminar» (plegada a ocho filas) e «Impacto de guardar». Un problema aparece junto a su campo, y en «Por corregir antes de guardar» como enlace a él, una vez que has tocado ese campo o has intentado guardar; bajo «Crear rol», una línea dice «Válido: nada que arreglar» o cuántos problemas quedan.
7. Pulsa «Crear rol». Se abre «Roles» con el aviso «Rol «…» creado.».

Un rol nuevo no concede nada hasta que se lo concedes a alguien (más abajo).

Ejemplo: desplegar con Argo CD, sin Secrets¶

Un equipo que despliega con Argo CD necesita ver sus cargas de trabajo, reiniciarlas y leer sus Application de Argo, sin Secrets:

• Capacidades: «Leer cargas de trabajo», «Escalar», «Eliminar Pods», «Leer logs», «Leer eventos».
• Una regla avanzada: «Grupo de la API» argoproj.io, «Recursos» applications, «Verbos» «Lectura» (get, list, watch).

El resumen lo marca como «Sensible», porque argoproj.io es un grupo ajeno a Kubernetes (Lo que kubelatch no puede saber), y no exige Pod Security: nada en él crea pods.

Duplicar un rol¶

Para partir de un rol que ya existe, elígelo en «Empezar desde» en el constructor, o elige «Duplicar» en su menú de fila o en su página: las dos cosas abren el constructor con ese chip pulsado, el mismo contenido y « (copia)» tras su nombre; cambia el nombre y el identificador lo sigue.

admin y cluster-admin enlazan los roles propios de Kubernetes y no se pueden duplicar. Una copia de viewer o de developer es una aproximación, y la línea bajo los chips lo dice: esos dos agregan además el rol view de Kubernetes y los ClusterRoles etiquetados de cada cluster, que una copia no hereda (Los roles de sistema en capacidades). Comprueba la copia frente a lo que necesita la persona antes de concederla en lugar del original.

Una copia de viewer conserva «Namespaces y todo el cluster», porque sus capacidades de todo el cluster lo necesitan. Para un rol de lectura solo por namespace, elige «Namespaces»: las cuatro capacidades de todo el cluster siguen marcadas y señaladas hasta que las apagas, y «Apagar las 4» lo hace de una vez.

Editar un rol¶

1. En «Roles», elige «Editar» en el menú de fila del rol, o «Abrir» y pulsa «Editar».
2. Cambia lo que necesites. El identificador es fijo.
3. Pulsa «Guardar cambios». Espera a que el resumen refleje lo que hay en pantalla.

Si ningún permiso usa el rol, se guarda al momento. Si alguno lo usa, kubelatch pregunta antes: «Guardar el rol «…»» dice cuántos permisos cambian y en cuántos clusters, y lista «Capacidades que se añaden», «Capacidades que se quitan» y, si es el caso, «Cambian las reglas avanzadas.». Al pulsar «Guardar», esos clusters se reconcilian al momento: en segundos los titulares tienen las reglas nuevas, con las credenciales que ya tienen.

kubelatch rechaza una edición que dejaría permisos activos que el rol ya no admite:

El resumen lo dice antes de guardar: la tarjeta de todo el cluster, la casilla del cluster o las capacidades muestran el problema con el número de permisos, y «Frente al rol guardado» lista «Deja de concederse a todo el cluster.» o «Quita los clusters: …»; la confirmación lo repite. Un permiso concedido entre el resumen y el guardado se sigue rechazando al guardar, con el mismo mensaje.

Aquí cuentan también los permisos de cuentas deshabilitadas, que «Uso» deja fuera. Los encuentras en «Permisos», en «Activos», marcados «Cuenta deshabilitada».

Si otra persona guardó el rol después de que lo abrieras, al guardar aparece «Alguien guardó este rol después de que lo abrieras.». Pulsa «Cargar la última versión»: tus cambios se quedan en pantalla, el resumen muestra en qué se diferencian de la versión guardada, y guardas de nuevo.

Cada edición es un role.update en el registro del plano de control, con la revisión anterior y la nueva, las capacidades añadidas y quitadas, y las reglas antes y después (Auditoría y retención).

Eliminar un rol¶

1. En «Roles», elige «Eliminar» en el menú de fila del rol, o «Eliminar» en la página del rol.
2. «Eliminar el rol «…»» comprueba qué permisos lo usan:
   • Ninguno: pulsa «Eliminar».
   • Alguno: el diálogo lista cada permiso activo, incluidos los de cuentas deshabilitadas, y ofrece «Revocar todos y eliminar». Los revoca y elimina el rol de una vez, y sus clusters se reconcilian al momento. También revoca los permisos de grupo que nombran el rol, y los permisos derivados de ellos, para que ningún grupo lo vuelva a dar.

El identificador no se vuelve a usar. Los permisos pasados y el registro de auditoría conservan el identificador del rol, y las listas lo muestran en lugar del nombre. Los roles de sistema no se pueden eliminar.

Conceder un rol personalizado¶

En «Permisos», «Conceder permisos» funciona igual que para un rol de sistema (Conceder permisos). En «Qué» van primero los «Roles de sistema» y después los «Roles personalizados». Un rol personalizado sale desactivado cuando el cluster elegido no lo admite:

Se aplican las mismas reglas que a un rol de sistema: ningún namespace protegido, el namespace tiene que existir, y un rol que exige Pod Security necesita la etiqueta pod-security.kubernetes.io/enforce con baseline o restricted. El ámbito «todo el cluster (*)» solo vale para un rol que se puede conceder a todo el cluster. Un rol personalizado no tiene límite de caducidad, así que «Nunca» está disponible.

En el cluster, el permiso es el grupo kubelatch:ns:<namespace>:role-<id>, o kubelatch:cluster:role-<id> con ámbito *. Para comprobar qué permite, usa kubectl auth can-i con ese grupo (Comprobar qué puede hacer alguien).

Qué ve quien no tiene el rol de administrador¶

Las personas y los bots sin el rol de administrador no ven «Roles». En «Inicio», la tarjeta de cada cluster tiene una fila por permiso, y cada fila nombra su rol: un rol personalizado por su nombre, con su descripción debajo. Por la API, cualquier sesión puede leer los roles, sus capacidades, reglas y riesgo, pero no su uso ni los clusters a los que se limitan (API HTTP).