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 ClusterRoleBindings that grant
pods/execto broad subjects- Run on: any machine with kubectl access
-
Inspect each implicated ClusterRole and its bindings
- Run on: any machine with kubectl access
Replace<clusterrole-name>with the name from the audit output.
- Run on: any machine with kubectl access
-
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:authenticatedname: system:unauthenticatedname: system:anonymouskind: Groupandname: system:serviceaccounts(or similar broad SA groups)
- Optionally add explicit human operators or specific groups, for example:
- Run on: any machine with kubectl access
-
If needed, split shared ClusterRoles to avoid giving
pods/execbroadly- Run on: any machine with kubectl access
When a ClusterRole is used by both broad and restricted bindings and only some needpods/exec:
- Run on: any machine with kubectl access
-
Point restricted operators at the new operators-only ClusterRole
- Run on: any machine with kubectl access
For bindings that should retainpods/exec, updateroleRef.name:
In the editor, change:to: - Run on: any machine with kubectl access
-
Verification: confirm no broad subjects have
createonpods/exec- Run on: any machine with kubectl access
Ensure the output isis_compliant=true.
Using kubectl
Using kubectl
On any machine with kubectl access:Look for rules like:b) Bind that role only to specific named users or a single dedicated SA (example with two Azure AD users):Adjust RoleBinding (namespaced):In the opened YAML, under If the binding is only used to grant Under
- Identify the offending bindings and their ClusterRoles (from the audit output)
- The binding kind/name/namespace
- The roleRef (ClusterRole name)
- The broad subject (e.g.
system:authenticated,system:serviceaccounts)
- Inspect the ClusterRole rules granting
pods/exec
- Restrict
pods/execto a small set of named human operators
pods/exec:subjects to your actual Azure AD user principals or a single service account as appropriate.- Remove broad subjects from existing offending bindings
system:authenticated, system:unauthenticated, system:anonymous, system:serviceaccounts, and (if present) any Group that represents all users.ClusterRoleBinding (cluster‑scoped):subjects:, delete entries like:pods/exec broadly and you have replaced it with the new, restricted binding, you can optionally delete the old binding entirely:- (Optional) Narrow the original ClusterRole if it is too broad
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:rules:, either:- Remove
"pods/exec"fromresources, or - Split rules so that non‑exec permissions stay in this ClusterRole, and exec is granted only by the new dedicated ClusterRole.
- Verification
create on pods/exec to broad subjects:Automation
Automation

