RoleBinding
Does ZopNight manage RoleBinding?
RoleBindings attach a Role or ClusterRole to subjects within a single namespace. Referencing a ClusterRole from a RoleBinding grants it only in that 1 namespace, the detail most people get backwards. ZopNight records roleRefKind, roleRefName, and subjectCount per binding, so each grant's shape is readable without enumerating subjects.
Rules that fire on RoleBinding
No active rule family targets RoleBinding today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A RoleBinding is where RBAC stops being theory: it attaches a Role, or a ClusterRole, to users, groups, or ServiceAccounts within one namespace. Definitions grant nothing on their own; the binding is the object that makes permissions live, which makes bindings the layer an access review actually reads.
roleRef: the kind field that changes everything
Every binding carries a roleRef naming what it grants, and discovery records its two halves, roleRefKind and roleRefName, plus a subjectCount. The kind field is the one to read carefully, because a RoleBinding may reference either a Role or a ClusterRole, and the two mean different things even in the same position.
The ClusterRole-in-a-RoleBinding pattern
Referencing a ClusterRole from a namespace RoleBinding is legal, common, and the detail most people get backwards: it does not grant cluster-wide access. The ClusterRole contributes only its permission list; the RoleBinding’s namespace bounds where those permissions apply. Binding the built-in edit ClusterRole to a team’s group in exactly 1 namespace is the canonical use: one maintained definition, many narrow grants, no copy-pasted Roles drifting apart. The recorded roleRefKind makes the pattern visible at inventory scale: bindings with kind ClusterRole in application namespaces are usually this idiom at work, not a mistake.
Counting subjects instead of naming them
The subjectCount summarizes how many identities a binding grants to without enumerating them into the inventory. High-subject bindings deserve attention proportional to what they reference. A dozen subjects on view is routine, a dozen on admin is a governance decision someone should be able to defend. Zero-subject bindings occur too, and they are pure clutter.
kubectl get rolebindings -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REF-KIND:.roleRef.kind,REF:.roleRef.name,SUBJECTS:.subjects[*].nameBroken references fail silently
A binding whose roleRef names a Role or ClusterRole that no longer exists grants nothing and raises nothing, because Kubernetes tolerates the dangling pointer indefinitely. Cross-checking binding roleRefs against the Role and ClusterRole inventory is the mechanical audit that finds both the dead grants and their scarier inverse: permissions that returned when someone recreated a deleted name.