Publicado: 2026-03-04
El equipo de investigación sobre seguridad en la nube de KENSAI analizó 12.000 clústeres de Kubernetes en producción de empresas europeas y descubrió que el 58 % contiene configuraciones incorrectas de RBAC (control de acceso basado en roles) lo bastante graves como para permitir el movimiento lateral y la escalada de privilegios hasta cluster-admin. Los cinco patrones más peligrosos —permisos comodín, abuso de cuentas de servicio predeterminadas, exceso de ClusterRoleBindings, escape del espacio de nombres mediante permisos para crear pods y montaje de tokens en pods privilegiados— están presentes en la mayoría de las implementaciones. La mayoría de las organizaciones no audita las políticas de RBAC después de la configuración inicial.
⚡ Si un atacante compromete cualquier pod en el 58 % de los clústeres analizados, puede escalar hasta obtener acceso completo de cluster-admin en cuestión de minutos únicamente mediante configuraciones incorrectas de RBAC.
La configuración incorrecta más extendida: el 23 % de los clústeres tiene ClusterRoles personalizados con verbos o recursos comodín (*). Los equipos copian el rol cluster-admin como punto de partida y olvidan limitar su alcance. Un solo pod con una cuenta de servicio vinculada a uno de estos roles obtiene acceso sin restricciones a todos los recursos de todos los espacios de nombres: secretos, configmaps, nodos y el propio servidor de la API.
# Peligroso: ClusterRole comodín
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← Equivalente a cluster-admin completo
Cada espacio de nombres de Kubernetes tiene una cuenta de servicio default que se monta automáticamente en los pods, salvo que se deshabilite explícitamente. En el 41 % de los clústeres, la cuenta de servicio predeterminada de al menos un espacio de nombres ha recibido permisos elevados, a menudo porque un operador ejecutó rápidamente kubectl create rolebinding durante una depuración y nunca lo revirtió. Los atacantes que consiguen ejecutar código de forma remota en cualquier pod de ese espacio de nombres heredan inmediatamente esos permisos.
El 34 % de los clústeres tiene más de 10 ClusterRoleBindings personalizados, es decir, vinculaciones que conceden permisos en todos los espacios de nombres. Muchos vinculan roles amplios a grupos como system:authenticated o system:serviceaccounts, lo que en la práctica concede acceso elevado a todos los usuarios autenticados o a todas las cuentas de servicio del clúster.
Los usuarios con permiso para create pods en cualquier espacio de nombres pueden montar el sistema de archivos del host, ejecutar contenedores privilegiados o crear pods con cualquier cuenta de servicio de ese espacio de nombres. En el 29 % de los clústeres, los desarrolladores tienen permisos para crear pods sin que se apliquen los Estándares de Seguridad de Pods, lo que permite escapar fácilmente del contenedor al nodo subyacente.
Kubernetes monta de forma predeterminada los tokens de las cuentas de servicio en los pods. Cuando esto se combina con especificaciones de pods privilegiados o acceso a la red del host, los atacantes pueden robar el token y autenticarse en el servidor de la API desde fuera del clúster. Solo el 12 % de los clústeres analizados establece automountServiceAccountToken: false en las cargas de trabajo que no necesitan acceso a la API.
get secrets en todos los espacios de nombres, por lo que el atacante extrajo credenciales de bases de datos, claves de API y certificados TLS en menos de 4 minutos.
Más de la mitad de los clústeres de Kubernetes en producción analizados contiene al menos una configuración incorrecta de RBAC que podría permitir escalar privilegios desde un pod comprometido hasta obtener acceso de cluster-admin.
En pruebas de penetración contra clústeres mal configurados, el tiempo medio desde el compromiso inicial de un pod hasta obtener acceso completo de cluster-admin fue de 3,2 minutos. Herramientas automatizadas como peirates y kubeletctl lo hacen trivial.
Los clústeres con permisos de lectura mediante comodines expusieron una media de 847 secretos de Kubernetes, entre ellos credenciales de bases de datos, claves de API, certificados TLS y tokens de IAM de proveedores de nube en todos los espacios de nombres.
La gran mayoría de las organizaciones configura RBAC una sola vez durante el aprovisionamiento del clúster y nunca vuelve a revisarlo. Las vinculaciones de roles se acumulan durante meses a medida que los equipos añaden permisos para depuración, canalizaciones de CI/CD y supervisión, y nunca los eliminan.
El módulo de seguridad de Kubernetes de KENSAI ahora incluye un análisis automatizado de RBAC que asigna cada cuenta de servicio, rol y vinculación de su clúster para identificar rutas de escalada de privilegios. El escáner genera un gráfico visual de las cadenas de permisos y destaca la ruta más corta desde cualquier carga de trabajo comprometida hasta cluster-admin.
Cada carga de trabajo debe tener su propia cuenta de servicio dedicada con solo los permisos que realmente necesita. Evite vincular ClusterRoles cuando sean suficientes Roles limitados al espacio de nombres. Utilice automountServiceAccountToken: false para los pods que no necesiten acceder a la API de Kubernetes, que son la mayoría de las cargas de trabajo de aplicaciones.
Los Estándares de Seguridad de Pods (PSS) de Kubernetes en el nivel restricted impiden que los pods se ejecuten como root, monten rutas del host o utilicen el modo privilegiado. Aplíquelos en el ámbito del espacio de nombres mediante Pod Security Admission. Esto elimina el vector de escape del contenedor incluso si los permisos de RBAC son demasiado amplios.
Implemente auditorías trimestrales de RBAC. Revise todos los ClusterRoleBindings, identifique vinculaciones obsoletas de miembros que ya no forman parte del equipo o de servicios retirados y valide que ninguna cuenta de servicio tenga permisos más amplios de lo necesario. KENSAI puede automatizar este proceso mediante la detección continua de desviaciones.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false en todas las cargas de trabajo que no necesiten acceso a la APIrestricted y en el ámbito del espacio de nombres para todas las cargas de trabajo en producciónkubectl get clusterrolebindings -o wide — marque cualquier elemento vinculado a grupos amplioskensai scan --k8s-rbac en su clúster para obtener una evaluación completa de los riesgos de RBAC en menos de 60 segundos. El informe incluye un gráfico de escalada de privilegios, pasos específicos de remediación para cada hallazgo y una correspondencia con los requisitos de NIS2 para las organizaciones sujetas a la directiva.
*) de los ClusterRoles personalizadossystem:authenticated o system:serviceaccountsautomountServiceAccountToken: false en todos los pods que no necesiten acceso a la APIrestricted para los espacios de nombres de producción🛡️ ¿Su sitio web es seguro?
Descubra las vulnerabilidades antes que los atacantes.
Analice su sitio web gratis →