More Info:
The bind, impersonate, and escalate verbs allow privilege escalation beyond a principals assigned permissions. They should only be granted where strictly required for cluster operation.Risk Level
HighAddress
SecurityCompliance Standards
- CIS AKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all Roles/ClusterRoles using bind/impersonate/escalate
- Run on: any machine with kubectl access
-
Exclude known Kubernetes system roles from modification
- Run on: any machine with kubectl access
- Identify roles that are likely required system roles and note them for special care (usually do not change without strong justification):
- For each ClusterRole/Role from step 1, check if its name starts with
system:or is clearly a control-plane/controller role; mark those as “system – review but generally keep”.
-
Inspect each non‑system ClusterRole/Role rule detail
- Run on: any machine with kubectl access
- For each name from step 1 that is not a system role, show full spec:
- For each, record:
- Which verb(s) are present:
bind,impersonate,escalate - Which
apiGroups,resources, andresourceNamesthey apply to - Whether the scope (cluster-wide vs namespace) matches a real operational need.
- Which verb(s) are present:
-
Identify who is bound to these powerful roles
- Run on: any machine with kubectl access
- For each binding, decide if each subject (user, group, service account) truly requires these verbs for its function. Flag any human users or generic service accounts as high priority to restrict.
-
Decide and apply least-privilege changes
- Run on: any machine with kubectl access
- For each non‑system role where use is not strictly required:
- Prefer narrowing permissions before removal:
- Remove unnecessary verbs (
bind,impersonate,escalate) from the rules. - Restrict resources / resourceNames to the minimal required set.
- Remove unnecessary verbs (
- If no subject legitimately needs those verbs, remove them entirely from the role.
- Prefer narrowing permissions before removal:
- Apply by editing the role definitions:
- If necessary, adjust bindings to use a different, less-privileged Role/ClusterRole instead of the powerful one.
-
Re-verify the cluster for remaining bind/impersonate/escalate use
- Run on: any machine with kubectl access
- Confirm that:
- Only necessary system roles and explicitly justified operational roles retain these verbs.
- Non-system users and service accounts no longer have unjustified access to them via RoleBindings/ClusterRoleBindings.
Using kubectl
Using kubectl
- Any
ClusterRoleorRolein the output whosemetadata.nameormetadata.namespacesuggests it belongs to:- Application-specific components (e.g. business apps, CI/CD jobs, monitoring agents), or
- Human users (e.g.
dev-*,qa-*,ops-*,admin-*), and whoserulescontain verbsbind,impersonate, orescalate.
- Roles not obviously part of Kubernetes’ own system roles/groups (for example, not starting with
system:and not documented as core cluster controllers) that have these verbs.
- Whether each non-system role truly needs
bind,impersonate, orescalatefor its function. - Whether these verbs can be removed or split into a more constrained role.
system:masters, clusterrole-aggregation-controller, or other documented system roles in your environment).Automation
Automation
- Any
ClusterRole:orRole:that is not a known system role and showsVerbs:containingbind,impersonate, orescalate. - Any
ClusterRoleBinding:orRoleBinding:where:roleRefpoints to one of those roles, andsubjectslist non-system users or service accounts (e.g., app service accounts in application namespaces).

