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
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
Identify which subjects can create pods
- Run on any machine with kubectl access:
- Run on any machine with kubectl access:
-
Inspect the exact permissions granting
createon pods- Run on any machine with kubectl access:
- Open
/tmp/clusterroles.yamland/tmp/roles.yamland search for rules like:
- Open
- Run on any machine with kubectl access:
-
Decide which roles should keep
createon pods- For each role/clusterrole you found, decide:
- Is pod creation truly required for this role’s function?
- Can the ability be restricted to specific namespaces (use Role instead of ClusterRole)?
- Can pod creation be delegated to a dedicated automation account instead of broad groups like
system:authenticatedorsystem:authenticated:oauth?
- Document which Role/ClusterRole objects must be tightened and which subjects (users/groups/serviceaccounts) should retain pod-creation rights.
- For each role/clusterrole you found, decide:
-
Remove or narrow
createpermissions on pods in roles/clusterroles- To edit a ClusterRole:
- To edit a namespaced Role:
- In the opened manifest, locate the rules containing
resources: ["pods"]and then:- Remove
"create"from theverbslist, or - If the entire rule is only for pod creation, delete that rule block.
- Remove
- Save and exit to apply the change.
- To edit a ClusterRole:
-
Adjust bindings so only intended subjects can create pods
- List bindings:
- Edit any binding that grants a pod-creating role to overly broad subjects:
- Under
subjects:, remove or replace broad subjects (for examplesystem:authenticated, large groups) with only those users/groups/serviceaccounts that should still be able to create pods.
- List bindings:
-
Verification
- Confirm that generic authenticated users can no longer create pods:
- The output should be
canCreatePodsAsSystemAuthenticated: noafter remediation.
- Confirm that generic authenticated users can no longer create pods:
Using kubectl
Using kubectl
On any machine with kubectl access:Then for each ClusterRole/Role you decide should not be able to create pods:Edit to:Apply the change:Repeat this export/edit/apply pattern for each Role/ClusterRole where you want to remove pod creation.Or edit bindings declaratively:
- Identify which RBAC bindings currently allow authenticated users to create pods
- Remove
createfrom theverbslist onpods(declarative edit)
developer that currently has create on pods, first export it:developer-clusterrole.yaml and in the relevant rule(s) adjust verbs so create is removed, for example change:- Optionally, break unnecessary subject bindings that grant pod creation
- Verification
Automation
Automation

