Views:
Profile applicability: Level 1 - Master Node
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 in a kubeadm cluster 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       clusterroleaggregation-
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-volumebinder
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.