More Info:
The ability to create pods can be abused to run privileged workloads or escalate privileges. This permission should be restricted to only required service accounts.Risk Level
HighAddress
SecurityCompliance Standards
- CIS AKS
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all Roles/ClusterRoles that can create pods
Run on any machine with kubectl access: -
Review each identified Role/ClusterRole’s scope and necessity
For each name from step 1, inspect full rules and annotations:Decide whether the subjects using this role truly need to create pods, or if they could use higher‑level abstractions (Deployments/Jobs) or narrower permissions instead. -
Identify who is bound to these Roles/ClusterRoles
For each Role/ClusterRole discovered, list RoleBindings/ClusterRoleBindings:Then inspect each binding to see which users/groups/serviceaccounts are granted pod creation: -
Decide and implement least-privilege changes
For each combination of Role/ClusterRole and binding:- If pod creation is not required: remove
createonpodsfrom the role rules.In the editor, deletecreatefrom theverbslist for thepodsresource, or remove the rule stanza entirely if no longer needed. - If some but not all subjects need this permission: create a new, narrowly scoped Role/ClusterRole just for those subjects, and update bindings so only those specific serviceaccounts/users/groups are bound to it.
- If pod creation is not required: remove
-
Tighten or remove unnecessary bindings
Where overly broad subjects are found (e.g., groups likesystem:authenticatedor wildcard-like coverage):- Replace broad bindings with bindings to specific service accounts or users that actually require pod creation.
- Remove RoleBindings/ClusterRoleBindings that are no longer needed:
-
Verify that pod creation access is minimized
Re-run the evidence commands to confirm only the intended Roles/ClusterRoles retain pod creation:Confirm that each remaining role withcreateonpodsis intentionally required and bound only to the minimal set of subjects.
Using kubectl
Using kubectl
Using kubectl
Run the following from any machine with kubectl access.- List all Roles/ClusterRoles that can create pods
- Inspect detailed rules for each identified role
<clusterrole-name> with each name from step 1):<namespace> and <role-name>):rules section, look for:resources: ["pods"](or includingpods)verbs: ["create"](or includingcreateor*)
Rules that allow
create on pods (directly, via * verbs, or via * resources) tied to functions that do not strictly require pod creation, or overly broad rules (e.g., verbs: ["*"] or resources: ["*"]).- See who is bound to these Roles/ClusterRoles
Bindings that grant these permissions to:
system:authenticated,system:unauthenticated, or other large groups.- Generic groups like “developers” or many service accounts that do not need to create pods.
- User/service account identities where pod creation is not part of their function.
- Quick check for obviously over‑broad bindings
Any of these broad subjects bound to roles that have
create on pods from step 1.- Verification after manual adjustments
kubectl edit or manifests), re-run:create and confirm they are restricted only to the specific service accounts/users that truly require this capability.Automation
Automation

