Kubernetes RBAC has Role, ClusterRole, RoleBinding and ClusterRoleBinding. Explain the scoping matrix — which combinations are legal and what each one actually grants — and what aggregated ClusterRoles are for.

## Two axes, not one Kubernetes separates **where the rules are defined** from **where they apply**. Role/ClusterRole is the definition axis; RoleBinding/ClusterRoleBinding is the application axis. That is why there are four objects and only three legal combinations. **Role** is a namespaced object. Its rules can only ever concern resources inside its own namespace, and it can only be referenced by a RoleBinding in that same namespace. **ClusterRole** is cluster-scoped. It is a *definition* of permissions — writing one grants nothing until it is bound. It is the only place you can express permissions over cluster-scoped resources (nodes, persistentvolumes, namespaces, clusterroles, storageclasses), over non-resource URLs (`/healthz`, `/metrics`), and the only definition reusable across namespaces. **RoleBinding** is namespaced and grants its `roleRef` inside its own namespace. It may reference either a Role in that namespace or any ClusterRole. **ClusterRoleBinding** is cluster-scoped, may reference only a ClusterRole, and grants those rules everywhere. ## The matrix in detail **Role + RoleBinding.** The straightforward case: rules written for and applied to one namespace. Use it when the permission set is genuinely specific to that namespace, for instance a rule with `resourceNames` naming that team's Secrets. **ClusterRole + RoleBinding — the scoped-down pattern.** You define the permission set once, cluster-wide, then bind it per namespace. The binding's namespace confines the grant. This avoids copying the same Role into forty namespaces and having them drift. Two subtleties: - Rules in the ClusterRole covering **cluster-scoped** resources are silently inert under a RoleBinding, because those objects have no namespace to be confined to. A ClusterRole granting `nodes` bound via RoleBinding gives no node access. - Rules covering **non-resource URLs** are likewise inert. **ClusterRole + ClusterRoleBinding.** Cluster-wide grant across every namespace, present and future, plus cluster-scoped resources. Reserve it for genuine cluster-wide roles: platform operators, monitoring agents that must list pods everywhere, controllers. Binding `cluster-admin` this way is the ultimate grant, and `kubectl get clusterrolebindings` is the first place to audit. **Role + ClusterRoleBinding.** Rejected by the API server. If it were allowed, a namespace-scoped object would be projecting authority outside its namespace — anyone with write access to a namespace's Roles could grant themselves cluster-wide power. The asymmetry is a deliberate security property. ## Subjects All four binding shapes carry the same `subjects` list: `User`, `Group` (opaque strings from the authenticator — Kubernetes stores no user objects) and `ServiceAccount` (a real object, referenced with name plus namespace, so a RoleBinding in namespace A can bind a ServiceAccount from namespace B). Group bindings are how you scale: bind an OIDC or certificate group, manage membership in the identity provider, and never touch RBAC again for joiners and leavers. `roleRef` is **immutable**. Retargeting a binding means delete-and-recreate; controllers that manage RBAC must handle that. ## Aggregated ClusterRoles A ClusterRole may declare an `aggregationRule` instead of writing rules directly: ```yaml kind: ClusterRole metadata: name: view aggregationRule: clusterRoleSelectors: - matchLabels: rbac.authorization.k8s.io/aggregate-to-view: "true" rules: [] # filled in by the controller manager ``` A controller in kube-controller-manager watches ClusterRoles, unions the rules of every ClusterRole matching the selectors, and writes the result into `rules`. Anything you hand-write into an aggregated role's `rules` is overwritten on the next reconcile. The built-in `view`, `edit` and `admin` are aggregated, which is what makes them extensible. When you install a CRD, you ship a tiny ClusterRole granting read on your custom resource, labelled `rbac.authorization.k8s.io/aggregate-to-view: "true"`, and every existing `view` binding in the cluster immediately gains that read — no edits to a built-in object that an upgrade would revert, and no per-namespace changes. `admin` and `edit` aggregate transitively (`aggregate-to-edit` labels also flow into `admin`), so labelling for edit generally covers admin too. The operational caution is blast radius: labelling a ClusterRole for aggregation instantly widens permissions for every subject already bound to the aggregate, cluster-wide. Aggregation labels deserve the same review as a binding change. ## Checking the result `kubectl auth can-i <verb> <resource> -n <ns> --as <user>` for a single question, `kubectl auth can-i --list --as <user> -n <ns>` for the effective set, and `kubectl describe clusterrole view` to see the aggregated rules the controller actually assembled.