Published: 2026-03-04
KENSAI's cloud security research team analyzed 12,000 production Kubernetes clusters across European enterprises and found that 58% contain RBAC (Role-Based Access Control) misconfigurations severe enough to allow lateral movement and privilege escalation to cluster-admin. The five most dangerous patterns — wildcard permissions, default service account abuse, excessive ClusterRoleBindings, namespace escape via pod creation rights, and token mounting in privileged pods — are present in the majority of deployments. Most organizations don't audit RBAC policies after initial setup.
⚡ If an attacker compromises any pod in 58% of scanned clusters, they can escalate to full cluster-admin within minutes using RBAC misconfigurations alone.
The most pervasive misconfiguration: 23% of clusters have custom ClusterRoles with wildcard (*) verbs or resources. Teams copy the cluster-admin role as a starting point and forget to scope it down. A single pod with a service account bound to such a role has unrestricted access to every resource in every namespace — secrets, configmaps, nodes, and the API server itself.
# Dangerous: Wildcard ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: devops-tools
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # ← Full cluster-admin equivalent
Every Kubernetes namespace has a default service account that is automatically mounted into pods unless explicitly disabled. In 41% of clusters, the default service account in at least one namespace has been granted elevated permissions — often because an operator ran a quick kubectl create rolebinding during debugging and never cleaned it up. Attackers who gain RCE in any pod in that namespace immediately inherit those permissions.
34% of clusters have more than 10 custom ClusterRoleBindings — bindings that grant permissions across all namespaces. Many bind broad roles to groups like system:authenticated or system:serviceaccounts, effectively granting elevated access to every authenticated user or every service account in the cluster.
Users with create pods permission in any namespace can mount the host filesystem, run privileged containers, or create pods with any service account in that namespace. In 29% of clusters, developers have pod creation rights without Pod Security Standards enforcement — enabling trivial container escape to the underlying node.
Kubernetes mounts service account tokens into pods by default. When combined with privileged pod specs or host network access, attackers can steal the token and authenticate to the API server from outside the cluster. Only 12% of scanned clusters set automountServiceAccountToken: false on workloads that don't need API access.
get secrets permission across all namespaces — the attacker extracted database credentials, API keys, and TLS certificates within 4 minutes.
More than half of production Kubernetes clusters analyzed contain at least one RBAC misconfiguration that could enable privilege escalation from a compromised pod to cluster-admin level access.
In penetration tests against misconfigured clusters, the average time from initial pod compromise to full cluster-admin access was 3.2 minutes. Automated tools like peirates and kubeletctl make this trivial.
Clusters with wildcard read permissions exposed an average of 847 Kubernetes secrets — including database credentials, API keys, TLS certificates, and cloud provider IAM tokens across all namespaces.
The vast majority of organizations configure RBAC once during cluster provisioning and never review it again. Role bindings accumulate over months as teams add permissions for debugging, CI/CD pipelines, and monitoring — and never remove them.
KENSAI's Kubernetes security module now includes automated RBAC analysis that maps every service account, role, and binding in your cluster to identify privilege escalation paths. The scanner generates a visual graph of permission chains and highlights the shortest path from any compromised workload to cluster-admin.
Every workload should have its own dedicated service account with only the permissions it actually needs. Avoid binding ClusterRoles when namespace-scoped Roles suffice. Use automountServiceAccountToken: false for pods that don't need Kubernetes API access — which is the majority of application workloads.
Kubernetes Pod Security Standards (PSS) at the restricted level prevent pods from running as root, mounting host paths, or using privileged mode. Enforce these at the namespace level using Pod Security Admission. This eliminates the container escape vector even if RBAC permissions are overly broad.
Implement quarterly RBAC audits. Review all ClusterRoleBindings, identify stale bindings from departed team members or decommissioned services, and validate that no service account has broader permissions than required. KENSAI can automate this with continuous drift detection.
kubectl get clusterroles -o json | jq '.items[] | select(.rules[]?.verbs[]? == "*")'automountServiceAccountToken: false on all workloads that don't need API accessrestricted PSS at namespace level for all production workloadskubectl get clusterrolebindings -o wide — flag anything bound to broad groupskensai scan --k8s-rbac against your cluster to get a complete RBAC risk assessment in under 60 seconds. The report includes a privilege escalation graph, specific remediation steps per finding, and NIS2 compliance mapping for organizations subject to the directive.
*) verbs and resources from custom ClusterRolessystem:authenticated or system:serviceaccountsautomountServiceAccountToken: false on all pods that don't need API accessrestricted level for production namespaces