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. Identify the offending bindings and roles (any machine with kubectl access)
  2. Inspect a flagged binding and its role (any machine with kubectl access)
    Replace the names from the finding/audit output.
  3. Decide how pods/exec should be used (manual review)
    • Determine which specific human users or a small set of named service accounts truly need kubectl exec.
    • For any broad subject (system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts), decide whether:
      • exec should be removed entirely for that binding, or
      • the binding should be replaced by a binding to specific users/groups/service accounts.
  4. Restrict or remove the broad binding (any machine with kubectl access)
    Example: edit an existing ClusterRoleBinding to remove broad subjects and add specific ones.
    In your editor:
    • Under subjects:, delete entries where name is any of:
      system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts.
    • Optionally add tightly scoped subjects such as:
    • Save and exit to apply.
  5. Optionally narrow the ClusterRole itself (any machine with kubectl access)
    If the ClusterRole grants more than needed (e.g., "resources: ["*"] or verbs: ["*"]), edit it:
    In your editor, change the relevant rule to something like:
    or remove pods/exec from resources entirely if exec is no longer required.
  6. Verify the remediation (any machine with kubectl access)
    Confirm the output is is_compliant=true and no bindings with broad subjects remain for pods/exec.
On any machine with kubectl access:
  1. Identify the offending bindings and roles
Focus on bindings where roleRef points to a Role/ClusterRole that allows create on pods/exec and subjects include any of:
  • system:authenticated
  • system:unauthenticated
  • system:anonymous
  • system:serviceaccounts
  1. Remove broad subjects from the binding
For each offending binding, edit it to remove the broad subject and (optionally) replace it with specific named users/groups.ClusterRoleBinding example (cluster‑wide):
In the editor, change e.g.:
to something like:
or remove the subjects entry entirely if no one should have pods/exec via this binding.RoleBinding example (namespace‑scoped):
Adjust the subjects section the same way: eliminate system:authenticated, system:unauthenticated, system:anonymous, or system:serviceaccounts, keeping only specific users or a single, named service account if absolutely required.
  1. (Optional) Split out a least‑privilege exec role
If a broad ClusterRole currently contains pods/exec among many other permissions, consider:
Edit /tmp/exec-role.yaml to:
  • Change metadata.name to a new, restrictive name, e.g. exec-operators-only.
  • Remove all rules except the minimal exec rule, for example:
Apply it:
Then create a dedicated binding for named human operators only:
  1. Verification
Run the provided audit on any machine with kubectl access: