Kubernetes RBAC: four misconfigurations we find every time

We review a lot of Kubernetes clusters. The same four RBAC problems appear in almost all of them, usually because a permission was widened during an incident and never narrowed afterwards.

1. Service accounts bound to cluster-admin

Usually a CI deployer that needed one extra permission at 2am. The result is that anyone who can run a pod under that service account owns the cluster. Enumerate ClusterRoleBindings to cluster-admin and justify every subject in writing; the ones you cannot justify are the ones to fix first.

2. Wildcard verbs on wildcard resources

A role granting verbs: ["*"] on resources: ["*"] is cluster-admin wearing a different name. Wildcards are almost never intentional at review time — they are what someone wrote to get unblocked.

3. Broad secret read access

Any principal that can read secrets namespace-wide can read every credential your workloads use, including ones that reach outside the cluster. Scope secret access to named resources with resourceNames, and prefer a real secrets manager with short-lived credentials over long-lived Kubernetes secrets.

4. The escalate and bind verbs

These two verbs bypass the privilege-escalation prevention that RBAC otherwise enforces. A principal with escalate on roles can grant itself permissions it does not have. It is rarely needed outside of controllers, and it is easy to miss in a review because it looks like an ordinary verb.

Making it stick

• Run kubectl auth can-i --list as each service account in CI and diff the output against a committed baseline
• Deny wildcard verbs at admission with a policy engine
• Give temporary permissions an expiry from the moment they are granted
• Review bindings on the same cadence as your access reviews — the evidence is reusable for SOC 2 and ISO 27001