Objects of type
PodSecurityPolicy govern the ability
to make requests on a pod that affect the
SecurityContext that will be
applied to a pod and container.
See PodSecurityPolicy proposal for more information.
A Pod Security Policy is a cluster-level resource that controls the
actions that a pod can perform and what it has the ability to access. The
PodSecurityPolicy objects define a set of conditions that a pod must
run with in order to be accepted into the system. They allow an
administrator to control the following:
|Control Aspect||Field Name|
|Running of privileged containers||
|Default set of capabilities that will be added to a container||
|Capabilities that will be dropped from a container||
|Capabilities a container can request to be added||
|Controlling the usage of volume types||
|The use of host networking||
|The use of host ports||
|The use of host’s PID namespace||
|The use of host’s IPC namespace||
|The SELinux context of the container||
|The user ID||
|Configuring allowable supplemental groups||
|Allocating an FSGroup that owns the pod’s volumes||
|Requiring the use of a read only root file system||
|Running of a container that allow privilege escalation from its parent||
|Control whether a process can gain more privileges than its parent process||
|Whitelist of allowed host paths||
Pod Security Policies are comprised of settings and strategies that control the security features a pod has access to. These settings fall into three categories:
rangeto be configured. Uses the first value of the range as the default. Validates against the configured range.
runAsUseror have the
USERdirective defined in the image. No default provided.
runAsUserto be specified.
seLinuxOptionsto be configured if not using pre-allocated values. Uses
seLinuxOptionsas the default. Validates against
seLinuxOptionsto be specified.
supplementalGroupsto be specified.
fsGroupID to be specified.
The usage of specific volume types can be controlled by setting the volumes field of the PSP. The allowable values of this field correspond to the volume sources that are defined when creating a volume:
The recommended minimum set of allowed volumes for new PSPs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.
empty. List of
HostPortRange, defined by
max(inclusive), which define the allowed host ports.
Gates whether or not a user is allowed to set the security context of a container
allowPrivilegeEscalation=true. This field defaults to
Sets the default for the security context
AllowPrivilegeEscalation of a container.
This bool directly controls whether the
no_new_privs flag gets set on the
container process. It defaults to
nil. The default behavior of
allows privilege escalation so as to not break setuid binaries. Setting it to
ensures that no child process of a container can gain more privileges than
This specifies a whitelist of host paths that are allowed to be used by Pods.
An empty list means there is no restriction on host paths used.
Each item in the list must specify a string value named
defines a host path to match. The value cannot be “
An example is shown below:
apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: custom-paths spec: allowedHostPaths: # This allows "/foo", "/foo/", "/foo/bar" etc., but # disallows "/fool", "/etc/foo" etc. - pathPrefix: "/foo"
Admission control with
allows for control over the creation and modification of resources based on the
capabilities allowed in the cluster.
Admission uses the following approach to create the final security context for the pod:
If a matching policy is found, then the pod is accepted. If the request cannot be matched to a PSP, the pod is rejected.
A pod must validate every field against the PSP.
Here is an example Pod Security Policy. It has permissive settings for all fields
Create the policy by downloading the example file and then running this command:
$ kubectl create -f ./psp.yaml podsecuritypolicy "permissive" created
To get a list of existing policies, use
$ kubectl get psp NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES permissive false  RunAsAny RunAsAny RunAsAny RunAsAny false [*] privileged true  RunAsAny RunAsAny RunAsAny RunAsAny false [*] restricted false  RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]
To modify policy interactively, use
$ kubectl edit psp permissive
This command will open a default text editor where you will be able to modify policy.
Once you don’t need a policy anymore, simply delete it with
$ kubectl delete psp permissive podsecuritypolicy "permissive" deleted
In order to use Pod Security Policies in your cluster you must ensure the following
extensions/v1beta1/podsecuritypolicy(only for versions prior 1.6)
In Kubernetes 1.5 and newer, you can use PodSecurityPolicy to control access to privileged containers based on user role and groups. Access to different PodSecurityPolicy objects can be controlled via authorization.
Note that Controller Manager must be run against the secured API port, and must not have superuser permissions. Otherwise requests would bypass authentication and authorization modules, all PodSecurityPolicy objects would be allowed, and user will be able to create privileged containers.
PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod.
Access to given PSP policies for a user will be effective only when creating Pods directly.
For pods created on behalf of a user, in most cases by Controller Manager, access should be given to the service account specified on the pod spec template. Examples of resources that create pods on behalf of a user are Deployments, ReplicaSets, etc.
For more details, see the PodSecurityPolicy RBAC example of applying PodSecurityPolicy to control access to privileged containers based on role and groups when deploying Pods directly.Create an Issue Edit this Page