djimn

Cada vez que entro a auditar un cluster de Kubernetes nuevo, hago la misma prueba: kubectl auth can-i --list --as=system:serviceaccount:<ns>:<sa> sobre dos o tres service accounts al azar. Casi siempre encuentro lo mismo.

1. ClusterRoleBindings que nadie recuerda por qué existen. Alguien necesitó desbloquear un despliegue hace meses, ató un ServiceAccount a cluster-admin “solo para probar”, y ese binding sigue vivo. Nadie lo revisa porque no rompe nada — hasta que ese ServiceAccount se ve comprometido y el radio de explosión es literalmente todo el cluster.

2. Roles con resources: ["*"] y verbs: ["*"] para evitar depurar permisos. Es más rápido dar todo que averiguar qué necesita realmente un Operator o un Job. El problema es que “más rápido hoy” se convierte en “imposible de auditar en seis meses”.

3. Service accounts que comparten permisos entre namespaces sin necesidad. Un RoleBinding que debería vivir en un namespace aparece replicado en cinco, normalmente copiado-pegado de un manifiesto de otro entorno.

4. Nadie audita qué ClusterRoles agregan a admin o edit vía aggregationRule. Es una de las formas más silenciosas de que un permiso “inofensivo” acabe dando acceso amplio sin que quede explícito en ningún manifiesto que revises directamente.

La checklist que aplico ahora antes de dar el visto bueno a cualquier RBAC nuevo:

• ¿Este ServiceAccount necesita permisos de cluster, o le basta con un namespace?
• ¿Puedo sustituir ["*"] por la lista real de recursos/verbos que usa el Operator o la app?
• ¿Este binding tiene fecha de caducidad o una razón documentada para existir?
• ¿Hay algún ClusterRole con aggregationRule que esté ampliando permisos sin que se vea a simple vista?

Ninguna de estas prácticas es nueva. El problema nunca es no saberlo — es que revisar RBAC no es urgente hasta el día que sí lo es.

¿Cuál de estos os suena más a “eso lo tenemos nosotros”?