Kubernetes RBAC review failed: clusterrolebinding audit error permission denied fix

TL;DR

Give the audit identity a read only cluster role built for review work, because RBAC enumeration needs list and get across every resource type the audit touches. Check which API groups the tool queries, bind a cluster role with get, list and watch removed down to get and list only where possible, and run the audit with the audit identity rather than a personal cluster admin. Capture per resource errors separately so one denied API group does not blank the whole review.

Kubernetes RBAC review failed: clusterrolebinding audit error permission denied fix

Use this when

• A cluster RBAC audit stops with forbidden errors on rolebindings or clusterroles.
• The audit works for whoever runs it manually with admin rights and fails in automation.
• Some namespaces report and others return denied.

Not for this skill when

• A workload own service account is denied in the cluster. That is application RBAC repair, not audit access.
• The audit completes and shows dangerous bindings. Triage the bindings instead of the tooling.

Steps

1. From the audit log list the exact resources and verbs that returned forbidden, grouped by API group, so the missing access is enumerated rather than assumed. Verify: denied resources and verbs are listed per API group.
2. Create a dedicated audit service account in a tooling namespace and a cluster role granting get and list on roles, rolebindings, clusterroles, clusterrolebindings and the other resource types the tool reads. Verify: the cluster role exists with read only verbs and the named resources.
3. Bind the cluster role to the audit service account, and for namespace scoped gaps add rolebindings in the namespaces the audit must read where cluster binding is not acceptable. Verify: the audit identity can list bindings in a previously denied namespace.
4. Run the audit using the service account credential and confirm it completes for core RBAC types before enabling optional API group collection. Verify: the core RBAC report generates with no forbidden errors.
5. Enable remaining collectors one API group at a time, extending the cluster role only for groups the report genuinely includes, and rerun after each addition. Verify: each added collector either works or its denial is a documented scope choice.
6. Reconcile the report subjects count against a manual count of bindings from kubectl for a sample namespace so the audit is proven complete, not merely error free. Verify: sample counts match between the audit and kubectl output.
7. Store the audit manifests with the review tooling and record the identity design in the evidence, so the next cluster review reuses the same least privilege audit access. Verify: the manifests and the design note are filed together.

Why it happens

RBAC auditing has a bootstrap problem: reading every binding in a cluster is itself a privileged act, and personal admin credentials hide that fact until automation runs with a lesser identity. A purpose built read only cluster role solves it without handing the audit job cluster admin, which would be an embarrassing finding in its own report. Splitting collectors by API group keeps the grant minimal and turns remaining denials into explicit scope decisions instead of silent blind spots.

Variants and edge cases

kubectl auth review audit forbidden rolebindings

The kubectl phrasing. Test the audit identity directly with auth can-i checks for list on each binding type.

RBAC audit tool needs cluster admin to run

The design phrasing. A read only cluster role is almost always sufficient; push back on admin requirements with the resource list.

some namespaces missing from RBAC review report

The gap phrasing. Per namespace denial usually means the identity relies on namespace bindings that were never created everywhere.

Edge cases to check before closing the review cycle:

• Aggregated API discovery can fail the whole run for one broken extension API. Set the tool to tolerate discovery errors where it supports it.
• Impersonation features in some tools need extra verbs. Grant them deliberately and note why, since they widen the audit identity power.
• Rotate the audit credential like any other service credential and include it in the review it performs.

Compatibility: Kubernetes RBAC roles and bindings, kubectl auth checks, cluster audit tooling for role review.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IrhBgb1jLooPBAzY7rMb6w