Why a Role by itself grants nothing

Kubernetes RBAC deliberately splits "what can be done" from "who can do it" into two separate object types — a Role or ClusterRole only defines a set of permissions in the abstract, and it has zero effect on the cluster until a RoleBinding or ClusterRoleBinding connects it to actual users, groups, or service accounts. That split is why a Role sitting in a manifest with no binding anywhere is functionally inert, and also why understanding a cluster's real access model requires reading roles and bindings together rather than either in isolation — which is exactly what this tool does by matching each binding's roleRef back to the role it names and rendering the combination.

Role vs. ClusterRole, and namespace vs. cluster scope

A Role (and its RoleBinding) is namespace-scoped — the permissions it grants only apply within one namespace, even if a ClusterRole with the same rules exists elsewhere. A ClusterRole can be used two ways: bound cluster-wide via a ClusterRoleBinding for cluster-scoped access, or bound to a specific namespace via an ordinary RoleBinding that references a ClusterRole by name — a common pattern for reusing a single permission template across many namespaces without duplicating the rule definitions. Getting this distinction wrong is a frequent source of "why does this service account have access it shouldn't" surprises, since a ClusterRoleBinding to a broad ClusterRole grants that access everywhere in the cluster, not just the namespace someone assumed it was scoped to.