Impact & Risk Analysis
- Severity: High
- CIS Benchmark: CIS 5.1.4
- Impact: Privilege Escalation. The ability to create pods is effectively root access to the cluster node unless strict Pod Security Standards are enforced. A user with
create podpermission can:- Create a pod that mounts the host’s root filesystem (
hostPath). - Create a pod that uses a highly privileged Service Account (e.g., one with
cluster-adminrights). - Run a privileged container to bypass isolation.
- Create a pod that mounts the host’s root filesystem (
Common Misconfiguration
Granting developers directcreate pod access to debug applications. Instead, developers should typically interact with higher-level controllers like Deployments, Jobs, or ReplicaSets, or use exec permissions on existing pods if debugging is needed.
Vulnerable Example
Secure Example
Audit Procedure
Review the users and roles who havecreate access to pod objects in the Kubernetes API.
- Analyze: Look for rules where
resourcescontainspodsANDverbscontainscreate. - Verify: Ensure this permission is limited to system controllers (like
replicaset-controller,job-controller) and cluster administrators.
Remediation
Where possible, removecreate access to pod objects in the cluster for standard users.
- Encourage users to deploy applications using Deployments, DaemonSets, or StatefulSets.
- If a user creates a Deployment, the Deployment Controller (a system component) creates the actual pod, not the user directly.
- Remove the explicit
pods/createrule from developer roles.

