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 ClusterRoleBindings that grant pods/exec to broad subjects
    • Run on: any machine with kubectl access
  2. Inspect each implicated ClusterRole and its bindings
    • Run on: any machine with kubectl access
      Replace <clusterrole-name> with the name from the audit output.
  3. Remove broad subjects from each non-essential binding and replace with named users/groups
    • Run on: any machine with kubectl access
      For each implicated ClusterRoleBinding <binding-name>:
    In the editor:
    • Under subjects:, remove any entries with:
      • name: system:authenticated
      • name: system:unauthenticated
      • name: system:anonymous
      • kind: Group and name: system:serviceaccounts (or similar broad SA groups)
    • Optionally add explicit human operators or specific groups, for example:
  4. If needed, split shared ClusterRoles to avoid giving pods/exec broadly
    • Run on: any machine with kubectl access
      When a ClusterRole is used by both broad and restricted bindings and only some need pods/exec:
  5. Point restricted operators at the new operators-only ClusterRole
    • Run on: any machine with kubectl access
      For bindings that should retain pods/exec, update roleRef.name:
    In the editor, change:
    to:
  6. Verification: confirm no broad subjects have create on pods/exec
    • Run on: any machine with kubectl access
    Ensure the output is is_compliant=true.
On any machine with kubectl access:
  1. Identify the offending bindings and their ClusterRoles (from the audit output)
Use the audit output to note:
  • The binding kind/name/namespace
  • The roleRef (ClusterRole name)
  • The broad subject (e.g. system:authenticated, system:serviceaccounts)
  1. Inspect the ClusterRole rules granting pods/exec
Look for rules like:
  1. Restrict pods/exec to a small set of named human operators
a) Create a dedicated ClusterRole that only grants pods/exec:
b) Bind that role only to specific named users or a single dedicated SA (example with two Azure AD users):
Adjust subjects to your actual Azure AD user principals or a single service account as appropriate.
  1. Remove broad subjects from existing offending bindings
For each binding reported by the audit as non‑compliant, edit it to remove broad subjects such as system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts, and (if present) any Group that represents all users.ClusterRoleBinding (cluster‑scoped):
RoleBinding (namespaced):
In the opened YAML, under subjects:, delete entries like:
If the binding is only used to grant pods/exec broadly and you have replaced it with the new, restricted binding, you can optionally delete the old binding entirely:
  1. (Optional) Narrow the original ClusterRole if it is too broad
If the original ClusterRole grants pods/exec alongside other permissions and is bound to many subjects, you can remove pods/exec from it and rely on the new exec-into-pods ClusterRole for exec access:
Under rules:, either:
  • Remove "pods/exec" from resources, or
  • Split rules so that non‑exec permissions stay in this ClusterRole, and exec is granted only by the new dedicated ClusterRole.
  1. Verification
Run the same logic used by the audit to confirm there are no bindings granting create on pods/exec to broad subjects: