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
HighAddress
SecurityCompliance Standards
- Cloudanix Best Practice
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify the offending bindings and roles (any machine with kubectl access)
-
Inspect a flagged binding and its role (any machine with kubectl access)
Replace the names from the finding/audit output. -
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.
- Determine which specific human users or a small set of named service accounts truly need
-
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 wherenameis any of:
system:authenticated,system:unauthenticated,system:anonymous,system:serviceaccounts. - Optionally add tightly scoped subjects such as:
- Save and exit to apply.
- Under
-
Optionally narrow the ClusterRole itself (any machine with kubectl access)
If the ClusterRole grants more than needed (e.g.,"resources: ["*"]orverbs: ["*"]), edit it:In your editor, change the relevant rule to something like:or removepods/execfromresourcesentirely if exec is no longer required. -
Verify the remediation (any machine with kubectl access)
Confirm the output is
is_compliant=trueand no bindings with broad subjects remain forpods/exec.
Using kubectl
Using kubectl
On any machine with kubectl access:Focus on bindings where In the editor, change e.g.:to something like:or remove the Adjust the Edit Apply it:Then create a dedicated binding for named human operators only:
- Identify the offending bindings and roles
roleRef points to a Role/ClusterRole that allows create on pods/exec and subjects include any of:system:authenticatedsystem:unauthenticatedsystem:anonymoussystem:serviceaccounts
- Remove broad subjects from the binding
subjects entry entirely if no one should have pods/exec via this binding.RoleBinding example (namespace‑scoped):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.- (Optional) Split out a least‑privilege exec role
pods/exec among many other permissions, consider:/tmp/exec-role.yaml to:- Change
metadata.nameto a new, restrictive name, e.g.exec-operators-only. - Remove all rules except the minimal exec rule, for example:
- Verification
Automation
Automation

