ClusterRoleBinding
Does ZopNight manage 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.
Rules that fire on ClusterRoleBinding
No active rule family targets ClusterRoleBinding today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
kubectl get clusterrolebindings -o custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name | grep cluster-adminSmall 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.