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 ClusterRoleBindings (any machine with kubectl access)
    Review the JSON output and list all bindings where subject.name is one of the “broad” subjects. Decide which bindings should be changed, and who the legitimate human operators are.
  2. Inspect each flagged binding to understand its scope and usage (any machine with kubectl access)
    Replace the names below with each binding from step 1:
    Confirm that the roleRef indeed needs pods/exec and determine the specific users or service accounts that should retain this ability.
  3. Remove broad subjects from the binding (any machine with kubectl access)
    For each flagged binding, edit it and remove any subjects entries with name: system:authenticated, system:unauthenticated, system:anonymous, or system:serviceaccounts. Keep or add only specific named users or a single, purpose-built ServiceAccount.
    In the editor, modify the subjects: list. Example before:
    Example after (replace with your real identities):
    Save and exit to apply changes.
  4. (Optional) Split shared bindings into dedicated ones (any machine with kubectl access)
    If a binding currently mixes broad subjects and specific operators, it may be clearer to:
    • Remove the broad subject from the existing binding (as in step 3), and
    • Create a dedicated binding for the specific operator(s), if one does not already exist:
    Adjust --user or use --serviceaccount=<namespace>:<sa-name> as appropriate.
  5. (Optional) Tighten the ClusterRole itself if it is overly broad (any machine with kubectl access)
    If a ClusterRole grants create on pods/exec (or * resources/verbs) more broadly than required, refine it:
    In the rules: section, restrict resources and verbs to the minimum necessary. For example, avoid resources: ["*"] or verbs: ["*"] if not strictly required. If possible, move pods/exec into a separate, tightly bound ClusterRole used only by the small set of human operators.
  6. Verify remediation (any machine with kubectl access)
    Re-run the audit and ensure it reports is_compliant=true or no offending rows:
On any machine with kubectl access:
  1. Identify the offending binding and role
  1. Remove broad subjects from the binding
Edit the binding to remove any of these subjects:
  • system:authenticated
  • system:unauthenticated
  • system:anonymous
  • system:serviceaccounts
In the subjects: list, delete any entries whose name is one of the above. Save and exit.Alternatively, patch to remove a specific subject (example for system:authenticated):
  1. Optionally, create a restricted ClusterRoleBinding for named human operators only
Prepare a manifest like:
Apply it:
  1. Verification (same logic as the audit)