# ClusterRoleBinding

> ClusterRoleBindings grant a ClusterRole across all namespaces at once, so a single careless binding, cluster-admin to a workload's ServiceAccount, is the highest-impact RBAC mistake available. ZopNight records each binding's roleRefName and subjectCount cluster-wide; filtering the inventory to cluster-admin references is step 1 of any RBAC audit.

Source: https://zop.dev/integrations/kubernetes/clusterrolebinding
Updated: 2026-08-19

---

A ClusterRoleBinding grants a ClusterRole to subjects across every namespace at once, present and future. There is no narrower version of what it does and no scope to fall back on: whatever the referenced ClusterRole permits, the subjects can do everywhere, which makes this the single highest-impact object type in Kubernetes RBAC.

## Cluster-wide grants have no undo scope

The comparison with a RoleBinding is the whole lesson. A RoleBinding referencing `cluster-admin` hands out sweeping permissions in one namespace; a ClusterRoleBinding referencing the same role hands out the cluster. The mistake pattern behind most Kubernetes security findings in this area is exactly that substitution: a workload's ServiceAccount bound to `cluster-admin` cluster-wide because a namespace-scoped grant kept hitting permission errors and someone escalated until the errors stopped.

## The audit that starts with one roleRef

Discovery records each binding's `roleRefName` and `subjectCount`, cluster-wide. Step 1 of any RBAC review is filtering that inventory to bindings whose roleRef is `cluster-admin` or another high-privilege role and reading the subject list of each. There should be a handful, they should be humans or break-glass groups, and every ServiceAccount among them needs a written justification. Controllers and operators legitimately hold broad bindings, but "the controller needs it" deserves verification against what the operator's documentation actually requests.

## How these bindings surface in discovery

ClusterRoleBindings map through the shared RBAC pipeline with an empty namespace, carrying `roleRefKind`, `roleRefName`, and `subjectCount` in metadata. The kind is ClusterRole by definition here, since the API allows nothing else in a ClusterRoleBinding's roleRef, so the interesting variance is entirely in which role and how many subjects.

```bash
kubectl get clusterrolebindings -o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name | grep cluster-admin
```

## Small population, disproportionate review value

Most clusters carry far fewer ClusterRoleBindings than RoleBindings, and the non-system subset is smaller still, often under 20 objects. Reviewing every one of them is an afternoon's work with permanent value, because this is the layer where a single stale grant equals standing cluster-wide access for whatever identity still holds it.