# 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.

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

---

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.

```bash
kubectl get rolebindings -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,REF-KIND:.roleRef.kind,REF:.roleRef.name,SUBJECTS:.subjects[*].name
```

## Broken 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.