# Role

> Roles grant verbs on resources inside exactly 1 namespace and cannot reach cluster-scoped objects like nodes or PersistentVolumes. ZopNight inventories each Role with its namespace and a ruleCount instead of the full rule list. Purpose-built Roles carry 1 to 5 rules, so high counts flag dumping grounds. Nothing applies until a RoleBinding attaches the Role to a subject.

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

---

A Role grants verbs on resources (get pods, create deployments, delete configmaps) inside exactly one namespace. It is the fine-grained end of Kubernetes RBAC, and the end you should reach for first: a Role can never accidentally leak permissions into another team's namespace, because the API scopes it there structurally.

## Scoped to one namespace by design

The namespace fence is the whole identity of the type. A Role cannot name cluster-scoped resources; nodes, PersistentVolumes, CRDs are simply outside its vocabulary. It cannot affect any namespace but its own. When a grant genuinely needs to cross namespaces or touch cluster-scoped objects, that is the ClusterRole's job; when the same permission set is merely needed in several namespaces, the cleaner pattern is one ClusterRole referenced by per-namespace RoleBindings rather than a copy-pasted Role in each.

## ruleCount as a review signal

Discovery records each Role with its namespace and a `ruleCount`, the number of policy rules it carries, rather than parsing the full rule list into the inventory. The count is a triage signal, not a verdict: most purpose-built Roles carry 1 to 5 rules, so a Role with dozens has usually become a dumping ground where permissions were appended over the years and never removed. Those are the ones worth opening in full.

## Inert until bound

A Role by itself grants nothing. Permissions only take effect when a RoleBinding attaches the Role to a subject: a user, group, or ServiceAccount. Roles with no binding referencing them are dead policy: harmless today, misleading tomorrow when someone binds to a stale grant assuming it was maintained. The inverse check matters more: bindings whose `roleRef` names a Role that no longer exists are broken grants that fail silently.

```bash
kubectl get roles -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,RULES:.rules --no-headers | head -30
```

## Where Roles sit in the audit

Namespace-scoped grants are the low-risk tier of the RBAC review, which is exactly why they should be the common case. The useful cluster-wide question this inventory answers is proportional: what share of grants lives in namespace-scoped Roles versus ClusterRoles? A ratio tilted toward cluster scope usually indicates convenience, not necessity.