Skip to main content

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

High

Address

Security

Compliance Standards

  • CIS AKS

Triage and Remediation

Remediation

Manual Steps

  1. List all Roles/ClusterRoles using bind/impersonate/escalate
    • Run on: any machine with kubectl access
  2. 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”.
  3. 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, and resourceNames they apply to
      • Whether the scope (cluster-wide vs namespace) matches a real operational need.
  4. 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.
  5. 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.
      • If no subject legitimately needs those verbs, remove them entirely from the role.
    • Apply by editing the role definitions:
    • If necessary, adjust bindings to use a different, less-privileged Role/ClusterRole instead of the powerful one.
  6. 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.
What indicates a problem:
  • Any ClusterRole or Role in the output whose metadata.name or metadata.namespace suggests 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 whose rules contain verbs bind, impersonate, or escalate.
  • 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.
You must manually decide:
  • Whether each non-system role truly needs bind, impersonate, or escalate for its function.
  • Whether these verbs can be removed or split into a more constrained role.
To inspect a specific suspicious role in more detail:
To see who is using a suspicious role:
Verification after you make any manual changes:
The remaining names should be only Kubernetes system roles that you have consciously approved to retain these permissions (for example, system:masters, clusterrole-aggregation-controller, or other documented system roles in your environment).
Output indicating a problem
  • Any ClusterRole: or Role: that is not a known system role and shows Verbs: containing bind, impersonate, or escalate.
  • Any ClusterRoleBinding: or RoleBinding: where:
    • roleRef points to one of those roles, and
    • subjects list non-system users or service accounts (e.g., app service accounts in application namespaces).