Views:
Profile applicability: Level 1
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).
As such, access to create new pods should be restricted to the smallest possible group of users.
The ability to create pods in a cluster opens up possibilities for privilege escalation and should be restricted, where possible.
Note
Note
By default, the following list of principals have create privileges on pod objects.
CLUSTERROLEBINDING                                     SUBJECT
TYPE                     SA-NAMESPACE
cluster-admin                                                   system:masters
Group
system:controller:clusterrole-aggregation-controller            clusterrole-
aggregation-controller ServiceAccount kube-system
system:controller:daemon-set-controller                         daemon-set-controller
ServiceAccount kube-system
system:controller:job-controller                                job-controller
ServiceAccount kube-system
system:controller:persistent-volume-binder                      persistent-volume-
binder ServiceAccount kube-system
system:controller:replicaset-controller                         replicaset-controller
ServiceAccount kube-system
system:controller:replication-controller                        replication-controller
ServiceAccount kube-system
system:controller:statefulset-controller                        statefulset-controller
ServiceAccount kube-system

Impact

Care should be taken not to remove access to pods to system components which require this for their operation.

Audit

Review the users who have create access to pod objects in the Kubernetes API.

Remediation

Where possible, remove create access to pod objects in the cluster.