Kubernetes normally stops you from granting rights you do not hold. Three verbs break that rule on purpose. Escalate lets you write roles with more rights than you have, bind lets you create bindings to roles you could not otherwise grant, and impersonate lets you act as someone else. Grant them rarely and narrowly.
The built-in guard
The RBAC reference describes privilege escalation prevention. You can only create or update a role if you already hold all of its permissions at the same scope, or you have the escalate verb on roles or clusterroles in the rbac.authorization.k8s.io group. For bindings, you need all of the referenced role's permissions at the same scope, or the bind verb on that role.
That guard is why a namespace admin cannot hand out cluster-admin. It is also why the exceptions deserve attention.
Escalate
The good practices page says the RBAC system generally prevents users from creating clusterroles with more rights than the user possesses, and that the exception is the escalate verb. Users with this right can effectively escalate their privileges.
Bind
Bind works like escalate but on bindings. Granting it allows a user to create bindings to roles with rights they do not already have. The RBAC reference shows a safe shape for this: a ClusterRole with the bind verb limited by resourceNames to the admin, edit and view roles, paired with permission to create rolebindings.
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin","edit","view"]
Naming the roles is the point. A bind verb with no resourceNames covers every role.
Impersonate
Impersonate lets a user gain the rights of other users in the cluster. The docs say care should be taken to ensure that excessive permissions cannot be gained through one of the impersonated accounts. The same page also describes a good use: a low-privileged account with impersonation rights can help prevent accidental changes, because an admin acts as the higher identity only when needed.
A review routine
- Search every role for the three verbs, including wildcards on verbs, which would include them.
- For each hit, write down who holds it and why.
- Add resourceNames to bind and impersonate grants wherever possible.
- Re-check after each upgrade of an operator that ships its own ClusterRoles.
Safeguard helps around this rather than inside the cluster: policies and gates can check manifest changes in pull requests, and compliance evidence automation can store the review record. It does not enforce RBAC for you.
Quick check
Does a namespace admin automatically hold escalate?
Not by the docs' description. Escalate and bind are explicit verbs, and the guard applies to anyone who lacks them.
How do I limit the bind verb?
Use resourceNames on the clusterroles rule so that only listed roles can be bound.
Sources
Last reviewed: 19 October 2026.
