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
HighAddress
SecurityCompliance Standards
- CIS EKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all ClusterRoles that grant bind/impersonate/escalate
- Run on: any machine with kubectl access
-
Inspect the detailed rules for those ClusterRoles
- Replace
<CLUSTERROLE>with each name from step 1 - Run on: any machine with kubectl access
- Replace
-
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
- For each
-
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).
- create/modify RoleBindings/ClusterRoleBindings (needs
- Mark each subject as:
- “Required” (document the justification), or
- “Excess” (should be removed or replaced with a less-privileged role).
- Confirm whether the subject (user/group/serviceaccount) is an infrastructure component or automation that must:
- For each binding found in step 3:
-
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:
-
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.
Using kubectl
Using kubectl
Any ClusterRole shown here is potentially sensitive and needs manual review.
rules::- Problematic verbs:
verbs: ["bind"]verbs: ["impersonate"]verbs: ["escalate"]
- Problematic resources (often combined with above verbs):
resources: ["clusterroles", "roles"]withbindresourcesincludingsubjectaccessreviews,selfsubjectaccessreviews,localsubjectaccessreviewswith wide verbs like["create","update","*"]
- Excessive wildcards:
verbs: ["*"]resources: ["*"]orapiGroups: ["*"]
subjects:):- Broad subjects:
kind: Group,name: system:authenticatedorsystem:serviceaccountskind: ServiceAccountwithout namespace scoping in your manifests/IaC
- Service accounts or users not clearly part of a privileged admin/CI/CD function.
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):
Automation
Automation
- Section 1 and 2: Any ClusterRole or Role listed here explicitly includes
impersonate,bind, orescalatein.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
*inverbs,resources, orapiGroups. 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.

