A quarterly RBAC review should look for four things: bindings to system:unauthenticated, wildcard rules, unused users and bindings, and escalation paths. The Kubernetes docs recommend regular review for redundant entries and possible escalation, and warn that a deleted user's name can be taken over.
Why review at all
Access accumulates. Permissions are purely additive, so nothing expires by itself. A binding created for a migration three years ago still grants everything it did the day it was made.
Check one: system:unauthenticated
The docs advise reviewing bindings for system:unauthenticated and removing them where possible, because they grant access to anyone who can reach the API server. The same principle applies to broad groups.
kubectl get clusterrolebindings,rolebindings -A -o wide | grep -E "system:unauthenticated|system:anonymous"
Some default bindings may appear, such as discovery roles. Know them, and investigate anything you did not expect.
Check two: wildcards
The RBAC reference says wildcards in resource and verb entries could result in overly permissive access to sensitive resources, and that you should name specific resources and verbs. The good practices page adds that wildcards also cover object types added later.
Check three: stale subjects
The docs advise deleting unused users and bindings, and explain why: if an attacker can create a user with the same name as a deleted user, they may inherit that user's rights. Remove the binding when the person leaves, not only the account in the identity system.
Compare binding subjects against your current staff list and your service account inventory. Use identity and secrets offboarding steps to keep the two in sync.
Check four: escalation paths
Look for escalate, bind and impersonate, CSR approval, token creation, nodes/proxy, webhook configuration edits, namespace patching and pod creation. Our posts on those cover each one, starting with the escalate, bind and impersonate verbs.
Make it repeatable
- Export the roles and bindings to a dated folder.
- Diff against last quarter. New cluster-wide grants get a named approver.
- Record the reviewer, the date and the changes. This is the evidence a SOC 2 or ISO 27001 style access review expects. Check your auditor's exact wording rather than assuming.
- Open tickets for removals and track them to closure.
Safeguard's compliance and evidence automation can store the review output and remind owners. It does not read your cluster RBAC itself.
Click through it at your own pace, or open it full screen.
Make findings small
Do not try to fix a whole cluster in one review. Pick the five highest-risk findings, fix them, and carry the rest to the next quarter with an owner. Small closed items beat a long open list.
Quick check
Why delete bindings for people who left?
Because, per the docs, someone who can create a user with the same name may inherit the deleted user's rights.
Sources
Last reviewed: 19 October 2026.
