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:
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:
*range*
to be configured. Uses the first value
of the range as the default. Validates against the configured range.*runAsUser*
or have the USER
directive defined in the image. No default
provided.*runAsUser*
to be specified.*seLinuxOptions*
to be configured if not using
pre-allocated values. Uses *seLinuxOptions*
as the default. Validates against
*seLinuxOptions*
.*seLinuxOptions*
to be
specified.*supplementalGroups*
to be
specified.*fsGroup*
ID 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, and secret.
empty
. List of HostPortRange
, defined by min
(inclusive) and max
(inclusive), which define the allowed host ports.Admission control with PodSecurityPolicy
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
psp.yaml
|
---|
|
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
:
$ 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]
To modify policy interactively, use kubectl edit
:
$ kubectl edit psp permissive
This command will open a default text editor where you will be ably to modify policy.
Once you don’t need a policy anymore, simply delete it with kubectl
:
$ 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
PodSecurityPolicy
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. To limit access to PodSecurityPolicy objects for pods created via a Deployment, ReplicaSet, etc, the Controller Manager must be run against the secured API port, and must not have superuser permissions.
PodSecurityPolicy authorization uses the union of all policies available to the user creating the pod and the service account specified on the pod. When pods are created via a Deployment, ReplicaSet, etc, it is Controller Manager that creates the pod, so if it is running against the unsecured API port, all PodSecurityPolicy objects would be allowed, and you could not effectively subdivide access. Access to given PSP policies for a user will be effective only when deploying Pods directly. 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