Kubernetes RBAC Misconfiguration.

Over-permissive Kubernetes Role/ClusterRole bindings that grant workloads, users, or service accounts cluster-wide powers — verbs on Secrets, pods/exec, impersonate — turning a single compromised container into cluster takeover. Es gehört zur Kategorie Cloud-Sicherheit der Cybersicherheit.

Over-permissive Kubernetes Role/ClusterRole bindings that grant workloads, users, or service accounts cluster-wide powers — verbs on Secrets, pods/exec, impersonate — turning a single compromised container into cluster takeover.

Kubernetes RBAC misconfiguration is consistently in the top three findings of every cluster audit. The common patterns are: binding workloads to cluster-admin or to ClusterRoles with verbs `*` on resources `*`; granting `get`, `list`, or `watch` on `secrets` cluster-wide (which lets a pod read every secret in the cluster); allowing `pods/exec` (which lets the holder shell into any pod, including the API server's static pods on misconfigured clusters); allowing `impersonate` on users, groups, or serviceaccounts (which is full account takeover); and binding the default service account in `kube-system` to admin. The blast radius pattern is consistent: a compromised front-door container with one of these bindings allows an attacker to dump all Secrets (including service-account tokens), exec into other pods, modify webhooks, or impersonate the admin group. Mitigations include automated linting (kubescape, kube-bench, Polaris, Datree), admission policies (Kyverno, OPA Gatekeeper) that reject overpermissive bindings, periodic generation of a least-privilege Role from runtime audit logs (rakkess, audit2rbac), and rolling out Pod Identity / Workload Identity rather than cluster-wide tokens.

Schutzmaßnahmen gegen Kubernetes RBAC Misconfiguration kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.

Übliche alternative Bezeichnungen: K8s RBAC misuse, Overprivileged ServiceAccount.