Role
Does ZopNight manage 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.
Rules that fire on Role
No active rule family targets Role today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
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.
kubectl get roles -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,RULES:.rules --no-headers | head -30Where 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.