RBAC de Kubernetes (Kubernetes RBAC)
En seguridad cloud, el RBAC de Kubernetes es el modelo de control de acceso basado en roles que gobierna qué pueden hacer usuarios y cargas de trabajo dentro de un clúster. Es donde se concentran los permisos excesivos de un clúster y el camino más corto a administrador del clúster, y es lo bastante distinto del RBAC genérico como para merecer ficha propia, porque el modelo y los hallazgos difieren.
Cómo funciona
El RBAC de Kubernetes concede permisos vinculando sujetos (usuarios, grupos y cuentas de servicio) a roles que enumeran los verbos permitidos sobre unos recursos. Los roles viven en un espacio de nombres; los ClusterRoles se aplican a todo el clúster. Cada pod se ejecuta con una cuenta de servicio y, por defecto, el token de esa cuenta se monta dentro del pod, así que una carga de trabajo tiene identidad en el clúster la necesite o no. El acceso es aditivo: un sujeto puede hacer la unión de todo lo que le permiten sus vínculos. El modelo tiene la misma forma que el RBAC genérico, pero los recursos son objetos de Kubernetes, y algunos verbos sobre algunos objetos son de hecho administrativos, que es donde vive el riesgo específico.
Qué sale mal
Ciertos permisos son más potentes de lo que parecen, y eso es lo primero que mapea un atacante. Poder crear pods, entrar en ellos con exec, leer secretos o modificar los vínculos de roles se puede escalar en cada caso hasta el control total del clúster, porque un pod se puede programar para ejecutarse en modo privilegiado, montar el anfitrión o usar una cuenta de servicio más potente. En los clústeres que probamos, el fallo recurrente son concesiones demasiado amplias: verbos con comodín, cluster-admin repartido por comodidad, o la cuenta de servicio de una carga de trabajo con permisos muy por encima de su cometido. Un pod comprometido hereda entonces esa identidad, y si la identidad puede leer secretos o crear pods privilegiados, el escape de contenedor apenas importa, porque el token por sí solo ya es la escalada.
Dónde aparece esto en una auditoría
Enumeramos el grafo de RBAC como lo haría un atacante: desde cada identidad alcanzable, qué puede hacer y si algún camino lleva a administrador del clúster. Marcamos los verbos peligrosos (create y exec sobre pods, read sobre secretos, modify sobre vínculos) allí donde se concedan más ampliamente de lo que exige el mínimo privilegio, y comprobamos si un admission controller acota lo que esos permisos pueden llegar a programar. El hallazgo es el camino de escalada, demostrado. Esto forma parte de cómo revisamos los permisos de un clúster.