More Info:
The ability to create pods in a namespace can provide a number of opportunities for privilege escalation, such as assigning privileged service accounts to these pods or mounting hostPaths with access to sensitive data (unless Pod Security Policies are implemented to restrict this access)Risk Level
LowAddress
SecurityCompliance Standards
- APRA CPS 234 (Australia)
- BSI C5 (Germany)
- Brazil LGPD
- CCPA / CPRA (California)
- CIS Critical Security Controls v8
- CIS GKE
- CMMC 2.0
- CSA Cloud Controls Matrix v4
- DPDPA
- Digital Operational Resilience Act (EU)
- Essential 8
- ISO/IEC 27017
- ISO/IEC 27018
- ISO/IEC 27701
- KSA PDPL
- MAS Technology Risk Management (Singapore)
- MITRE ATT&CK (Cloud)
- NIST SP 800-171
- NYDFS 23 NYCRR 500
- SWIFT Customer Security Controls Framework
- Sarbanes-Oxley IT General Controls
- UK NCSC Cyber Assessment Framework
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify who can create Pods in each namespace
Run on any machine withkubectlaccess:To list all subjects withcreateonpods(Role/RoleBinding + ClusterRole/ClusterRoleBinding):Inspect/tmp/rb-crb.yamlto map roles withcreateonpodsto users/groups/serviceaccounts. -
Review necessity of Pod creation for each subject
For each Role/ClusterRole that allowscreateonpods, decide if it is truly needed:Cross-check with application/CI/CD design docs and workload requirements for that namespace; flag any human users or broad groups (e.g.system:authenticated) that don’t require direct pod creation. -
Scope down or remove excessive Pod creation permissions
For each unnecessary permission, edit the binding or role:In the editor, removecreatefromverbsunder the rule withresources: ["pods"], or delete the whole rule if Pod access is not required. -
Prefer higher-level or constrained permissions where needed
For subjects that legitimately need to run workloads, replace direct Pod creation with safer alternatives where possible:- Grant permissions on
deployments,statefulsets,jobs, etc. instead ofpods. - If Pod creation is required, constrain it using:
create podsremains necessary and why. - Grant permissions on
-
Re‑verify effective permissions after changes
Re-run access checks to confirm that unnecessary Pod creation rights are removed:For specific high‑risk identities (e.g. human admins, CI service accounts), validate explicitly: -
Optionally test by simulating Pod creation attempts
For a sampled set of users/service accounts:Expect failure (no, or “forbidden”) for identities that should not be able to create Pods, and success only for those explicitly approved. Clean up any test Pods you created:
Using kubectl
Using kubectl
Using kubectl
Run these commands from any machine withkubectl access.1. Find who can create pods cluster-wide
- Any
ClusterRolewhereverbsincludescreateandresourcesincludespodsmeans cluster-wide permission to create pods. - Especially review broad roles like
cluster-admin,edit, or custom roles used by many subjects.
ClusterRoles:ClusterRoleBindingobjects that bind the above roles tosystem:authenticated, large groups (e.g.developers), or service accounts not meant to manage workloads indicate over-granting.
2. Find who can create pods in each namespace
List allRoles that allow pod creation:- Any
Rolein sensitive namespaces (e.g.kube-system,security,prod) withresources: ["pods"]andverbsincludingcreateneeds careful justification.
Roles:prod):RoleBindings that attach pod-creatingRoles to broad groups or many service accounts (e.g. generic CI accounts, default service accounts) signal overly permissive pod-creation rights.
3. Use kubectl auth can-i to spot effective access
Test specific identities (substitute actual user or service account):yesfor--all-namespacesor in sensitive namespaces for identities that should not manage workloads indicates excessive access to create pods.
Automation
Automation

