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
-
List all Roles/ClusterRoles that grant
createonpods/exec
Run on: any machine with kubectl access -
Identify “broad” bindings to those Roles/ClusterRoles
Run on: any machine with kubectl access -
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/execand document that set. - Plan to delete the broad binding and create new bindings only to those named identities.
- For each listed binding, determine which specific human users or service accounts truly need
-
Remove a non‑justified broad binding to
pods/exec
Run on: any machine with kubectl access- For a ClusterRoleBinding:
- For a RoleBinding (namespace‑scoped):
- For a ClusterRoleBinding:
-
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/execonly to a specific user: - Example: bind to a single service account in a namespace:
- Example: bind an existing ClusterRole that includes
-
Verify that no broad subjects are granted
createonpods/exec
Run on: any machine with kubectl accessConfirm the output isis_compliant=true.
Using kubectl
Using kubectl
On any machine with kubectl access:In the editor, adjust to something like:Make sure no remaining subject has In the editor, delete or narrow any rule that includes
- Identify the offending bindings and roles
- Inspect a specific flagged binding and its role
- Remove broad subjects from the binding
system:authenticated, system:unauthenticated, system:anonymous, and system:serviceaccounts are removed and replaced with a small set of named human users or dedicated groups.subjects from something like:name equal to any of:
system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts.- If needed, remove
pods/execfrom a shared ClusterRole
pods/exec into a dedicated, tightly bound role.a) Remove pods/exec from the shared ClusterRole: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:- Verification
create on pods/exec:Automation
Automation

