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.
|  | NoteBy default, the following list of principals have  createprivileges onpodobjects.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. 
		