Skip to main content

More Info:

The bind, impersonate, and escalate permissions allow subjects to acquire additional privileges within the cluster. Remove these rights from subjects wherever possible.

Risk Level

High

Address

Security

Compliance Standards

  • CIS EKS

Triage and Remediation

Remediation

Manual Steps

  1. List all ClusterRoles that grant bind/impersonate/escalate
    • Run on: any machine with kubectl access
  2. Inspect the detailed rules for those ClusterRoles
    • Replace <CLUSTERROLE> with each name from step 1
    • Run on: any machine with kubectl access
  3. Identify where these ClusterRoles are bound (who gets these rights)
    • For each <CLUSTERROLE> from step 1, list ClusterRoleBindings and RoleBindings that reference it:
    • Run on: any machine with kubectl access
  4. Decide which subjects truly require bind/impersonate/escalate
    • For each binding found in step 3:
      • Confirm whether the subject (user/group/serviceaccount) is an infrastructure component or automation that must:
        • create/modify RoleBindings/ClusterRoleBindings (needs bind),
        • act on behalf of other users (needs impersonate),
        • change privilege levels or assign high-privilege roles (needs escalate).
      • Mark each subject as:
        • “Required” (document the justification), or
        • “Excess” (should be removed or replaced with a less-privileged role).
  5. Remove or reduce excessive permissions from bindings and/or roles
    • To remove a subject from a binding (safer than deleting the role):
    • Run on: any machine with kubectl access
    • If a ClusterRole is used only to provide bind/impersonate/escalate and is no longer needed:
    • Alternatively, edit the ClusterRole to remove those verbs from its rules:
  6. Verify that bind/impersonate/escalate are now limited
    • Re-run the initial discovery and ensure only justified, documented roles remain:
    • For any remaining roles listed, confirm that their bindings (step 3) match the “Required” subjects decided in step 4.
Problem indication:
Any ClusterRole shown here is potentially sensitive and needs manual review.

What to look for:Within rules::
  • Problematic verbs:
    • verbs: ["bind"]
    • verbs: ["impersonate"]
    • verbs: ["escalate"]
  • Problematic resources (often combined with above verbs):
    • resources: ["clusterroles", "roles"] with bind
    • resources including subjectaccessreviews, selfsubjectaccessreviews, localsubjectaccessreviews with wide verbs like ["create","update","*"]
  • Excessive wildcards:
    • verbs: ["*"]
    • resources: ["*"] or apiGroups: ["*"]
These indicate the role can grant or exercise extra privileges and must be justified.
What to look for in bindings (subjects:):
  • Broad subjects:
    • kind: Group, name: system:authenticated or system:serviceaccounts
    • kind: ServiceAccount without namespace scoping in your manifests/IaC
  • Service accounts or users not clearly part of a privileged admin/CI/CD function.
Bindings that give these roles to wide groups or non-admin workloads are strong problems.
Problem indication:
Namespace Roles that grant these verbs to regular application service accounts or broad groups should be treated as misconfigurations unless there is a clear, documented need.

Verification after manual review/changesAfter you manually adjust roles/bindings (via edited manifests/IaC):
You should be able to account for every remaining ClusterRole listed and validate that only strictly necessary, well-justified subjects are bound to them.
Explanation of output that indicates a problem:
  • Section 1 and 2: Any ClusterRole or Role listed here explicitly includes impersonate, bind, or escalate in .rules[].verbs. These are directly problematic and must be reviewed; remove those verbs unless strictly necessary.
  • Section 3 and 4: ClusterRoles/Roles listed here use * in verbs, resources, or apiGroups. These broad grants may indirectly allow impersonation or privilege escalation; they should be narrowed or redesigned.
  • Section 5 and 6: For each risky role, these sections show the RoleBindings/ClusterRoleBindings and their subjects. If high-privilege or many subjects are bound (e.g., generic groups like system:authenticated), that indicates higher risk.