ClusterRole
Does ZopNight manage 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.
Rules that fire on ClusterRole
No active rule family targets ClusterRole today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
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?