RBAC de Kubernetes

Un Role define permisos (verbos sobre recursos) dentro de un namespace; un ClusterRole define permisos para todo el clúster o para recursos que no viven en un namespace. Los permisos no se aplican hasta que un enlace los une a un sujeto: un RoleBinding da el rol en un namespace, un ClusterRoleBinding lo da en todo el clúster. Un ClusterRole puede enlazarse con RoleBinding para limitarlo a un namespace.

Por eso el alcance real de un permiso se lee en el enlace, no solo en el rol.

El rol cluster-admin es el comodín de Kubernetes: todo sobre todo. Está pensado para quien administra el clúster, no para una cuenta que automatiza despliegues. Una cuenta de servicio con ese rol convierte el robo de su token en la entrega del clúster. En el RBAC, los sujetos aparecen como User, Group o ServiceAccount.

Abre enlaces.yaml y busca quién tiene el rol más amplio.

Leer Secrets suele subestimarse. En Kubernetes, quien puede hacer get o list sobre Secrets obtiene sus valores, y entre ellos están credenciales de bases de datos y tokens de otras cuentas de servicio. Un permiso de «solo lectura» sobre Secrets no es solo lectura de inocuidades: es acceso a credenciales.

Compara lo que el cliente dice que el grupo de soporte necesita (ver pods) con lo que el rol realmente concede y a quién llega.

Además de leer y escribir, RBAC tiene verbos especiales sobre los propios roles. Uno permite crear o editar roles con más permisos de los que tiene quien los edita; otro permite enlazar roles que uno no posee; otro, actuar como otro usuario. Se conceden pensando en «administrar roles» y rompen el techo que RBAC pone por defecto: alguien con permiso para editar roles puede acabar dándose a sí mismo lo que quiera.

Revisa editor-de-roles y el comentario que lo acompaña.

Corregir no es solo quitar permisos: es sustituirlos por lo que la tarea realmente necesita. La tubería solo despliega aplicaciones en dos namespaces; revisa notas.txt y piensa qué se le concede en su lugar.