# ClusterRole

> ClusterRoles define permissions that can span every namespace and reach cluster-scoped resources (nodes, PersistentVolumes, CRDs) that namespace Roles cannot name. ZopNight maps them through the same pipeline as Roles, with an empty namespace and a ruleCount each. Review separates the 4 default user-facing roles (cluster-admin, admin, edit, view) and system: plumbing from custom grants.

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

---

A ClusterRole defines permissions with no namespace fence: it can name cluster-scoped resources such as nodes, PersistentVolumes, CRDs and namespaces themselves. Bound cluster-wide, it reaches into every namespace at once. That reach is why ClusterRole review is the highest-leverage half of an RBAC audit.

## What cluster scope adds over a Role

Three capabilities separate the types. A ClusterRole can grant on cluster-scoped resources a namespace Role cannot even name; it can grant on non-resource URLs such as health and metrics endpoints; and one definition can serve many namespaces instead of being copy-pasted per team. Discovery maps ClusterRoles through the same pipeline as Roles, with an empty namespace and a `ruleCount` per object, so both halves of the RBAC surface land in one inventory with a consistent shape.

## Built-ins versus custom grants

Every cluster ships with dozens of system ClusterRoles, so raw counts mislead. The review that works separates 3 populations: the 4 default user-facing roles (`cluster-admin`, `admin`, `edit`, `view`) whose semantics are documented and stable; the `system:` prefixed plumbing that controllers require and humans should not touch; and everything else: the custom grants, where wildcard verbs on wildcard resources hide. Rule counts make the shortlist cheap: hand-written ClusterRoles with unusually many rules are the first ones to open.

## Scope is set twice, in definition and binding

The subtlety most people miss: a ClusterRole's effective reach depends on what binds it. Referenced by a ClusterRoleBinding it applies everywhere; referenced by a namespace RoleBinding the identical definition grants only within that one namespace. Defining permissions once as a ClusterRole and narrowing per namespace at binding time is the intended reuse pattern, not a loophole. It also means the definition alone never tells you the blast radius.

```bash
kubectl get clusterroles --no-headers | grep -cv '^system:'
```

## Reading the inventory

The command above counts non-system ClusterRoles, the reviewable population. For each, the questions are mechanical: does anything still bind it, could its grants live in a namespace Role instead, and do any rules use wildcards that a concrete list would serve better?