escalate clusterroles
Write permissions into a ClusterRole beyond what you already hold.
The escalate verb removes the check that normally blocks this, letting you patch an already-bound ClusterRole to inject */* directly with no bind needed.
Creating a new ClusterRole and self-binding it still requires bind on clusterroles separately.
- API Group
- rbac.authorization.k8s.io
- Scope
- cluster
- Audit Level
- RequestResponse
Escalation Paths
Use the escalate verb to bypass privilege-escalation prevention
Patch own bound ClusterRole to add */* rules (must be a role already bound to you)
Permissions expand via the existing binding.
No bind is needed when patching an already-bound ClusterRole.
Creating a new role and self-binding it requires bind clusterroles separately
Additional rights needed:
· escalate plus a way to write the rules
· editing an already-bound role needs no new binding
Note:
This is a by-design capability, not a CVE.
The escalate verb bypasses privilege-escalation prevention, so any identity holding it can grant permissions it does not already have.
No patch exists.
Create or update a ClusterRole with an aggregation label such as rbac.authorization.k8s.io/aggregate-to-admin: true.
The ClusterRole aggregation controller merges its rules into the built-in admin/edit/view role.
Prevention applies at write time.
Without escalate, only rules the caller holds can be injected.
With escalate, any rules can be injected regardless of caller permissions.
All principals bound to the role gain injected permissions.
T0 only where admin/edit is cluster-bound or the namespace holds cluster-admin credentials.
Additional rights needed:
· escalate plus a way to write the labelled role
· relabelling an existing role also works
Note:
Escalation prevention blocks injection of rules the caller does not hold, even with an aggregate-to-admin label.
The escalate verb is required to inject arbitrary rules.
Without it, only rules the caller already possesses can be aggregated.