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. Cette notion relève de la catégorie Sécurité du cloud en cybersécurité.

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.

Les défenses contre Kubernetes RBAC Misconfiguration combinent habituellement des contrôles techniques et des pratiques opérationnelles, comme détaillé dans la définition ci-dessus.

Noms alternatifs courants : K8s RBAC misuse, Overprivileged ServiceAccount.