Kubernetes refuses to let a user create a Role granting permissions they do not themselves hold, unless they have the escalate verb. Explain that privilege-escalation prevention rule, what the bind verb does, and how it shapes delegating RBAC administration to teams.

## Why RBAC needs a special rule about itself RBAC objects are ordinary API resources, so "who may write Roles" is itself an RBAC question. That creates a bootstrapping hazard: if writing a Role were a plain `create` permission, then anyone with `create` on `roles` in their namespace could author a Role granting anything — read all Secrets, exec into any pod — bind it to themselves, and have escalated. Namespace-level delegation would be equivalent to cluster-admin. Kubernetes closes this with two checks performed by the RBAC authorizer on writes to RBAC objects themselves. ## Check 1 — privilege escalation prevention on role writes When you `create` or `update` a `Role` or `ClusterRole`, the API server verifies that **every rule in the object is already permitted to you** in the relevant scope. If any rule exceeds your own permissions the write is rejected: ``` roles.rbac.authorization.k8s.io "x" is forbidden: user "alice" (groups=...) is attempting to grant RBAC permissions not currently held ``` Scope matters: writing a namespaced Role is checked against your permissions *in that namespace*, so a namespace admin can freely author Roles covering anything they themselves can do there. Writing a ClusterRole is checked cluster-wide. The waiver is the **`escalate`** verb on `roles`/`clusterroles`. A subject holding it may write roles containing permissions they lack. Treat holding `escalate` on `clusterroles` as equivalent to cluster-admin, because the holder can write themselves a cluster-admin-equivalent role in one step (they still need to bind it, but `bind`/`escalate` are usually granted together to the operators that need them). Legitimate holders are controllers and operators that install RBAC as part of a chart or CRD lifecycle. ## Check 2 — binding requires holding, or bind Creating a `RoleBinding`/`ClusterRoleBinding` is guarded too. To bind a role you must either: - hold every permission the referenced role contains (same escalation check), **or** - hold the **`bind`** verb on that role, ideally narrowed with `resourceNames`. `bind` is the precise delegation primitive. It says: *you may hand out this specific, pre-approved role, even though you do not hold it yourself.* A platform team can curate a `ci-deployer` ClusterRole and grant application teams `bind` on exactly that name; the team can then create RoleBindings attaching it to their own ServiceAccounts, and can neither modify the role nor invent a broader one. ```yaml rules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] resourceNames: ["ci-deployer"] verbs: ["bind"] ``` Note the subtlety: `resourceNames` works here because binding references a *named* role, exactly the case `resourceNames` was built for. ## The built-in admin role The default `admin` ClusterRole, bound with a **RoleBinding**, is the intended "namespace owner" grant. It includes write on `roles` and `rolebindings` in that namespace, so the team can self-serve RBAC for their own workloads. The escalation check is what makes that safe: an admin can only author roles containing permissions `admin` itself confers in that namespace. They cannot grant node access, cannot grant cluster-scoped resources, cannot exceed themselves. This is why the correct answer to "how do I let teams manage their own RBAC?" is almost never a custom broad role — it is `admin` scoped by RoleBinding, plus targeted `bind` grants for anything centrally curated. ## Adjacent escalation paths the rule does not cover The escalation check is about *writing RBAC*. Several other permissions escalate without touching an RBAC object, and reviewers should treat them as equivalently sensitive: - **`impersonate`** on users/groups/serviceaccounts — act as anyone, including a cluster-admin identity. Frequently the forgotten one. - **`create` on `pods`** in a namespace with a powerful ServiceAccount — you can schedule a pod that mounts that SA's token and inherit it. Pod-create is therefore approximately "union of all ServiceAccount permissions in the namespace". - **`pods/exec`** — take over a running workload's identity. - **`get` on `secrets`** — read a ServiceAccount token or any credential. - **`create` on `serviceaccounts/token`** — mint tokens for other ServiceAccounts. - **Write on validating/mutating webhook configurations, or on CRDs** — subvert admission for the whole cluster. A meaningful RBAC review enumerates who holds these across all bindings, not just who holds `cluster-admin`. ## Auditing Practical checks: list every ClusterRoleBinding and inspect its subjects; grep all Roles and ClusterRoles for the verbs `escalate`, `bind`, `impersonate` and for `*` in verbs or resources; and use `kubectl auth can-i --list --as <subject>` for each human group and each high-value ServiceAccount. Any `bind` grant without `resourceNames` should be justified — unrestricted `bind` on clusterroles means the holder can bind `cluster-admin`.