Monthlykubernetes-rbac-review

Kubernetes RBAC Review Checklist

10 items ·6 critical ·4 warn ·0 info

How to use this checklist

RBAC grants accumulate. This review is monthly because nobody ever removes a permission during an incident, and the incident is when they get added.

Mark an item N/A when it genuinely does not apply, and write down why. An unexplained N/A is the most common way a checklist stops working.

Sign-off

Every critical item must pass. A failing critical item blocks the deployment or the maintenance window; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical6 items

Enumerate every subject bound to cluster-admin and confirm each is still required and still employed.
```
kubectl get clusterrolebindings -o wide | grep cluster-admin
```
Enumerate every role granting escalate, bind, or impersonate. Each of these can be used to obtain more permission than it appears to grant.
```
kubectl get clusterroles -o json | jq -r '.items[] | select(.rules[]?.verbs[]? | test("escalate|bind|impersonate")) | .metadata.name'
```
Enumerate every subject that can read Secrets cluster-wide, and confirm each is a system component or a documented human role.
```
kubectl auth can-i list secrets --all-namespaces --as=system:serviceaccount:<ns>:<sa>
```
Enumerate every subject with pods/exec or pods/attach. This is shell access to production, and it should be logged and rare.
No in-house Role or ClusterRole uses `*` for resources or verbs.
The outcome of this review, including the decision to keep each cluster-admin binding, is written down with a date and a reviewer name.

Warning4 items

No non-system subject holds nodes/proxy — it bypasses much of the audit trail.
Bindings referencing ServiceAccounts, users, or groups that no longer exist are removed.
Each workload has its own ServiceAccount rather than sharing default, so that permissions can be scoped and revoked independently.
Permissions on CustomResourceDefinitions are reviewed alongside built-in resources — operators frequently ask for more than they need.