Skip to main content

More Info:

Advisory: review Roles/ClusterRoles that grant create on pods/exec. Exec into a running pod bypasses image immutability and admission controls.

Risk Level

High

Address

Security

Compliance Standards

  • Cloudanix Best Practice

Triage and Remediation

Remediation

Manual Steps

  1. List all Roles/ClusterRoles that grant create on pods/exec
    Run on: any machine with kubectl access
  2. Identify “broad” bindings to those Roles/ClusterRoles
    Run on: any machine with kubectl access
  3. Review and decide which broad bindings must be removed or replaced
    Run on: any machine with kubectl access
    • For each listed binding, determine which specific human users or service accounts truly need pods/exec and document that set.
    • Plan to delete the broad binding and create new bindings only to those named identities.
  4. Remove a non‑justified broad binding to pods/exec
    Run on: any machine with kubectl access
    • For a ClusterRoleBinding:
    • For a RoleBinding (namespace‑scoped):
  5. Create least‑privilege bindings for named subjects that actually need exec
    Run on: any machine with kubectl access
    • Example: bind an existing ClusterRole that includes pods/exec only to a specific user:
    • Example: bind to a single service account in a namespace:
  6. Verify that no broad subjects are granted create on pods/exec
    Run on: any machine with kubectl access
    Confirm the output is is_compliant=true.
On any machine with kubectl access:
  1. Identify the offending bindings and roles
  1. Inspect a specific flagged binding and its role
Replace the names from the audit output accordingly:
  1. Remove broad subjects from the binding
Edit the binding so that subjects like system:authenticated, system:unauthenticated, system:anonymous, and system:serviceaccounts are removed and replaced with a small set of named human users or dedicated groups.
In the editor, adjust subjects from something like:
to something like:
Make sure no remaining subject has name equal to any of: system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts.
  1. If needed, remove pods/exec from a shared ClusterRole
If a ClusterRole is broadly bound and you cannot safely constrain the subjects, move pods/exec into a dedicated, tightly bound role.a) Remove pods/exec from the shared ClusterRole:
In the editor, delete or narrow any rule that includes pods/exec or resources: ["*"] with verbs: ["create"] (or "*"), unless it is strictly needed for that broad audience.b) Create a dedicated ClusterRole and bind only specific operators:
  1. Verification
Run the same style of check to confirm no broad subjects are granted create on pods/exec: