Description
Users who can create Pods can choose images, service accounts, volumes and security settings within an authorized namespace. Admission policies and other controls also constrain what they can run. Permission to create pods is therefore a sensitive permission that can enable privilege escalation, not merely object creation.
Combining creation permissions with wildcard resources or verbs makes access particularly broad. Grant Pod creation only to identities that need it and at the narrowest necessary scope.
Potential impact
- Users may create Pods that use powerful service accounts or sensitive volumes.
- Privilege escalation or movement within the cluster may become easier.
- Broad RBAC grants can make operational control more difficult.
Remediation
- Restrict
createaccess topodsto identities that need it. - Avoid wildcard combinations such as
resources: ["*"]orverbs: ["*"]. - Treat Pod creation as a sensitive permission during RBAC reviews.
Examples
These examples compare role definitions. Check the bindings that grant these roles and permissions from other roles as well.
Before
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-creator
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- "get"
- "watch"
- "create"
After
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs:
- "get"
- "watch"
- "list"
Explanation:
- Before: Pod creation can let users obtain higher execution privileges indirectly.
- After: This role grants only Pod read permissions. Verify that other roles do not still grant creation access.