Roles y enlaces del orquestador, leer manifiestos

Un Role lista acciones permitidas sobre recursos, dentro de un solo espacio de nombres. Un ClusterRole hace lo mismo pero puede aplicarse a todo el clúster. Ninguno de los dos da acceso a nadie por sí solo: lo da el enlace (RoleBinding o ClusterRoleBinding), que une el rol con unos sujetos, que pueden ser cuentas de servicio, usuarios o grupos.

Un ClusterRoleBinding es más amplio que un RoleBinding: concede el rol en todos los espacios de nombres.

El rol cluster-admin permite cualquier acción sobre cualquier recurso, y si se concede con un ClusterRoleBinding, en todos los espacios de nombres. Es el permiso que ninguna cuenta de servicio de una aplicación debería tener. Busca en los enlaces del clúster quién lo recibe.

ls permisos
cat permisos/enlaces.yaml
grep -B3 -A3 cluster-admin permisos/enlaces.yaml

Un secreto del orquestador guarda credenciales de las aplicaciones. Quien tiene la acción de leerlo (get, list o watch sobre secrets) ve su contenido: el valor está codificado, pero no cifrado de forma útil para quien lo lee. En los roles del espacio de nombres, identifica el que concede esa lectura.

cat permisos/roles.yaml

Para saber quién puede leer los secretos de un espacio de nombres hay que sumar dos fuentes: los enlaces del propio espacio que apuntan al rol anterior y los enlaces de clúster con permisos totales. Los grupos y las personas se revisan aparte; aquí se cuentan solo las cuentas de servicio. Lee también las notas de la revisión para saber qué rol de lectura no incluye secretos.

cat permisos/notas-de-la-revision.txt
cat permisos/enlaces.yaml

La corrección se redacta, no se aplica: quitar la cuenta predeterminada del enlace que da lectura de secretos, reemplazar el permiso total por un rol limitado a lo que el tablero necesita y, si la aplicación necesita un secreto concreto, dar acceso solo a ese recurso por nombre. Antes de retirar un enlace se mira en el registro de auditoría si se usó, para no cortar un servicio.