Description
RBAC permissions bind and escalate are highly sensitive. bind allows binding a role containing permissions the caller does not hold, provided the caller also has permission to create or update the binding. With role creation or update access, escalate allows including permissions the caller does not hold in a role.
These permissions delegate control over access itself. Limit them to a small set of trusted administrators rather than ordinary users or service accounts.
Potential impact
- Users may define or bind roles that exceed their original permissions.
- A compromised account may gain administrative privileges quickly.
- Broad grants can undermine RBAC controls throughout the cluster.
Remediation
- Grant
bindandescalateonly to the minimum necessary administrators. - Separate ordinary-user roles from administrative roles.
- Review sensitive verbs alongside creation and update access to
clusterroles,roles,rolebindingsandclusterrolebindings.
Examples
These examples compare role definitions; bindings that grant these permissions to identities are omitted.
Before
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: rbac-binder
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["create"]
After
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: not-rbac-binder
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterrolebindings"]
verbs: ["create"]
Explanation:
- Before: Combining
bindwith ClusterRoleBinding creation allows binding a role with greater permissions than the caller holds. - After: This role no longer grants
bind. Binding creation remains allowed, but without a separate bind grant, the caller must already hold the referenced role’s permissions.