Autenticación y autorización del clúster (RBAC leído)

5 tareas · 40 min · Principiante

El benchmark dedica una sección a las políticas de RBAC porque es donde un clúster bien configurado en su arranque se vuelve inseguro con el uso: un permiso de más concedido «para salir del paso» se queda años. No se trata de escribir RBAC desde cero, sino de leerlo como lo hace un auditor: quién tiene cluster-admin, qué roles usan comodines, qué grupos son demasiado amplios. En Pasto Verde Agro lees la exportación de los ClusterRoleBinding y los roles del namespace tienda de un clúster de pruebas. Todo es lectura de exportaciones; no se cambia ningún permiso.

0 de 5 · 0%

Objetivo de la sala

En RBAC no existen reglas de denegación: un permiso se concede con un rol (qué verbos sobre qué recursos) y se asigna con un binding (a quién). Los permisos de un sujeto son la suma de todos los roles que le llegan, por cualquier binding, directo o por pertenecer a un grupo. Para quitar un acceso hay que quitar o estrechar el binding o el rol que lo concede: no se puede «prohibir» encima.

Esa propiedad cambia cómo se audita: no basta mirar los permisos de una persona, hay que mirar también los de todos los grupos a los que pertenece.

Responde para continuar

Una persona tiene un rol de lectura y, por su grupo, un binding a un rol de administración. ¿Qué permisos tiene?

Solo los de lectura, porque el binding directo manda sobre el del grupo Los de administración solamente, porque el rol más amplio sustituye al más estrecho Los de lectura y los de administración, porque los permisos de RBAC se suman

Ver pista de ayuda

RBAC no tiene denegaciones ni prioridades: suma todo lo concedido.

Los grupos system: los gestiona el propio clúster. system:authenticated incluye a toda identidad que haya pasado la autenticación: cada usuario, cada cuenta de servicio y cada nodo. Un binding a ese grupo no concede el permiso a «quienes lo necesitan»: lo concede a todos. Cuando el rol es cluster-admin, cualquier credencial válida del clúster es administradora.

Abre la exportación de ClusterRoleBinding y busca ese caso.

Responde para continuar

Escribe el nombre del ClusterRoleBinding que concede cluster-admin a todas las identidades autenticadas.

Ver pista de ayuda

Con la terminal, `cat rbac/clusterrolebindings.txt` y mira la columna de sujetos de las filas con cluster-admin.

Un rol con * en apiGroups, resources y verbs equivale a administrador dentro de su namespace: puede leer secretos, crear pods con cualquier configuración y cambiar los permisos del propio namespace. El comodín suele aparecer por comodidad («para que el despliegue no falle») y es una de las comprobaciones manuales del benchmark. Un rol bien escrito enumera el recurso y el verbo.

Revisa los roles del namespace tienda.

Responde para continuar

Escribe el nombre del rol del namespace tienda que usa comodín en grupos, recursos y verbos.

Ver pista de ayuda

Abre `rbac/roles-tienda.yaml` y busca las reglas con `"*"` en las tres listas.

El control del benchmark sobre cluster-admin pide que solo se use donde sea necesario. El primer paso para evaluarlo es contar: cuántos bindings le dan ese rol y a quién. Algunos son legítimos (los del propio clúster, como el grupo system:masters); otros son decisiones de personas. La cifra se compara con lo que el equipo esperaba, y la diferencia es la conversación.

Cuenta los ClusterRoleBinding que apuntan al rol cluster-admin.

Responde para continuar

¿Cuántos ClusterRoleBinding de la exportación apuntan al rol cluster-admin?

Ver pista de ayuda

Recorre la columna ROL de la exportación y cuenta las filas con `ClusterRole/cluster-admin`.

Quitar el binding amplio de golpe puede romper a quien hoy depende de él. El orden sano es: averiguar quién lo usa de verdad (el registro de auditoría lo dice), crear los permisos concretos que esas personas necesitan, moverlas y solo entonces retirar el binding. Retirarlo primero y esperar las quejas es la forma más rápida de que alguien vuelva a concederlo sin pensar.

Responde para continuar

Tienes que retirar el binding que da cluster-admin a todo el que se autentica. ¿Qué haces antes de retirarlo?

Revisar en el registro de auditoría quién lo usa, crear roles concretos para esos usos y después retirarlo Sustituirlo por un binding a cluster-admin para un grupo más pequeño, y revisar el resultado en un trimestre Eliminarlo ya mismo, porque cualquier permiso necesario se concederá de nuevo cuando alguien se queje

Ver pista de ayuda

Antes de quitar un permiso hay que saber quién lo usa y qué necesita de verdad.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 RBAC solo suma

2 Un grupo que lo incluye a todos Lab

3 Comodines en un rol Lab

4 Contar a los administradores Lab

5 Cómo se retira un permiso amplio

Whoami-Labs Pro utiliza cookies