Aggregation Labels on Custom ClusterRoles Silently Expand Kubernetes RBAC Permissions

Symptom

An identity that is bound only to the built-in edit or admin ClusterRole succeeds at an API operation that nobody explicitly granted it, and kubectl auth can-i confirms the access even though no RoleBinding or ClusterRoleBinding naming that identity has changed. Audit logs show the permission was never assigned through a binding at all, which makes the escalation look impossible until the actual mechanism is found.

False Assumption

Teams reviewing RBAC changes typically assume permissions can only reach an identity through an explicit RoleBinding or ClusterRoleBinding, so they audit bindings and conclude the system is safe when none have changed. This assumption ignores that Kubernetes ClusterRoles can carry an aggregationRule and that any other ClusterRole with a matching label is folded into that role’s rules automatically, with no binding involved at either end.

Root Cause

Kubernetes documents authorisation and policy controls as first-class security concerns, and RBAC’s aggregation mechanism is part of that model: a built-in ClusterRole such as edit defines a label selector, and every ClusterRole in the cluster carrying a matching label (for example rbac.authorization.k8s.io/aggregate-to-edit: "true") has its rules merged into that built-in role by the control plane. A platform team or a third-party add-on can apply this label to a narrow, purpose-built ClusterRole intended for one controller, and from that point on every identity already bound to edit silently inherits the merged rules. No RoleBinding is created, updated or reviewed, so binding-focused audits never surface the change.

Impact

The blast radius extends to every principal already bound to the affected built-in role, cluster-wide or per namespace depending on how that role is bound elsewhere, and the exposure grows again each time a new ClusterRole with a matching aggregation label is created. Because the change bypasses RoleBinding review entirely, teams that gate access changes on binding diffs have no signal that privilege has expanded, which can extend to secrets access, pod exec or workload creation depending on which rules were merged.

Diagnosis

Diagnosis stays entirely read-only until the offending label is confirmed. List every ClusterRole carrying an aggregation label for the role in question, inspect the built-in role’s current merged rule set, and confirm the effective permission against a real bound identity before treating the label as the cause.

Correction

Correction means removing the aggregation label from the ClusterRole that should never have been merged into a built-in role, so its rules stop flowing into that role without deleting the ClusterRole itself or any workload that depends on it. If the ClusterRole’s original purpose still requires its own permissions, keep the ClusterRole and its dedicated RoleBinding; only the aggregation label is removed.

Validation

Validation confirms the built-in role’s merged rule set no longer contains the unintended rules and that the specific identity used to reproduce the symptom no longer passes the kubectl auth can-i check for that action. Re-run the same diagnostic listing and the same can-i probe used during diagnosis so the before-and-after comparison is exact.

Rollback

Rollback restores the aggregation label on the ClusterRole if removing it breaks a controller or automation that unexpectedly depended on the merged permission. Because the change is a single metadata label rather than a deleted object, rollback is a label re-application or a re-apply of the ClusterRole’s prior manifest, and it should be validated with the same can-i probe before the incident is closed.

Prevention

Treat any ClusterRole labelled with an aggregation selector as equivalent in review weight to a direct RoleBinding change, since it has the same effect on real identities. Require aggregation labels to be reviewed explicitly in change control, run the diagnostic listing command as a recurring check rather than a one-off, and document which built-in roles are extended by design so an unexpected addition is easy to spot against a known baseline.