More Info:
The bind, impersonate and escalate verbs allow a subject to acquire additional privileges beyond those directly granted. Their use should be tightly restricted.Risk Level
HighAddress
SecurityCompliance Standards
- CIS GKE
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all roles/clusterroles using bind/impersonate/escalate
- Run on: any machine with kubectl access
- Command (given):
-
For each risky Role/ClusterRole, identify who uses it and why
- Run on: any machine with kubectl access
- For a ClusterRole:
- For a namespaced Role:
- Use this to decide if the subject truly needs bind/impersonate/escalate or could operate with lesser privileges (e.g., read/update only).
-
Narrow or remove risky verbs where not strictly required
- Run on: any machine with kubectl access
- Fetch the role for editing:
- In the YAML file, for each rule containing
bind,impersonate, orescalate:- Remove those verbs entirely when they are not required, or
- Move them into a more restricted role intended only for a small set of trusted subjects.
- Apply the edited role:
-
Where risky verbs are necessary, scope access as tightly as possible
- Run on: any machine with kubectl access
- In the same YAML files:
- Replace
resources: ["*"]or broad resource sets with the minimum concrete resources (e.g.,["roles","rolebindings"]instead of["*"]). - If feasible, separate duties:
- One role with normal verbs (get/list/watch/create/update/delete) for day‑to‑day tasks.
- A distinct, rarely used, strongly controlled role with
bind/impersonate/escalate.
- Replace
- Re‑apply with
kubectl apply -fas in step 3.
-
Tighten bindings to trusted subjects only
- Run on: any machine with kubectl access
- For each RoleBinding/ClusterRoleBinding referencing a role that still uses any of these verbs:
- Export, edit, and re‑apply:
- In the YAML, remove untrusted/unused subjects from
subjects:and keep only tightly controlled identities (e.g., a break‑glass admin group). - Apply:
- Export, edit, and re‑apply:
-
Re‑run the audit to verify and document accepted exceptions
- Run on: any machine with kubectl access
- Verification command (same as step 1):
- For any remaining entries, explicitly document why the risky verb is required, who owns it, and how access is controlled (break‑glass, approval workflow, etc.).
Using kubectl
Using kubectl
- Any line in this table is a role that uses at least one of:
bind,impersonate, orescalate. - Treat these as potentially risky and review each role for necessity and scope.
- Rules where
verbsincludesbind,impersonate, orescalate, especially when:resources: ["*"]or very broad resources are present.apiGroups: ["*"]or cross-namespace/global impact is visible.- There is no clear, tightly scoped operational need.
ClusterRoleBindingsubjects that are:- Broad groups (e.g.,
system:authenticated,system:serviceaccounts, wildcard-like SSO groups). - Service accounts in default or shared namespaces that many workloads can use.
- Human users/groups that do not need role-binding, impersonation, or escalation capabilities.
- Broad groups (e.g.,
- RoleBindings that grant these verbs to:
- Many service accounts or all service accounts in a namespace.
- Shared or default service accounts.
- Broad user groups where only a few operators should have the capability.
- You must still manually assess necessity, but a reduction in rows or narrowed resources/subjects shows progress in limiting
bind,impersonate, andescalateusage.
Automation
Automation
- The first table lists every
RoleorClusterRolethat uses any of the risky verbs inVERBS(one or more ofbind,impersonate,escalate) and whichRESOURCESthey apply to. - Any line in this table indicates a potential problem and must be manually reviewed:
- Confirm whether that role truly needs the listed verb(s).
- If not strictly required, plan to remove the verb(s) from that role’s rules.
- The JSON section (if it succeeds) is for deeper analysis: it links each risky role to bindings and subjects. Any subject bound to these roles is a candidate for privilege reduction.

