Skip to main content

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

High

Address

Security

Compliance Standards

  • CIS GKE

Triage and Remediation

Remediation

Manual Steps

  1. List all roles/clusterroles using bind/impersonate/escalate
    • Run on: any machine with kubectl access
    • Command (given):
  2. 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).
  3. 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, or escalate:
      • 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:
  4. 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.
    • Re‑apply with kubectl apply -f as in step 3.
  5. 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:
  6. 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.).
Problem indication:
  • Any line in this table is a role that uses at least one of: bind, impersonate, or escalate.
  • Treat these as potentially risky and review each role for necessity and scope.
Problem indication in the YAML:
  • Rules where verbs includes bind, impersonate, or escalate, 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.
Same problem indicators as above, but scoped to a namespace.
Problem indication:
  • ClusterRoleBinding subjects 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.
Problem indication:
  • 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.
Verification indication:
  • You must still manually assess necessity, but a reduction in rows or narrowed resources/subjects shows progress in limiting bind, impersonate, and escalate usage.
How to interpret the output
  • The first table lists every Role or ClusterRole that uses any of the risky verbs in VERBS (one or more of bind, impersonate, escalate) and which RESOURCES they 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.