website

12 KiB

Raw Blame History

approvers

title

pweil-

Pod Security Policies

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.

TOC {:toc}

What is a Pod Security Policy?

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	`privileged`
Default set of capabilities that will be added to a container	`defaultAddCapabilities`
Capabilities that will be dropped from a container	`requiredDropCapabilities`
Capabilities a container can request to be added	`allowedCapabilities`
Controlling the usage of volume types	`volumes`
The use of host networking	`hostNetwork`
The use of host ports	`hostPorts`
The use of host's PID namespace	`hostPID`
The use of host's IPC namespace	`hostIPC`
The SELinux context of the container	`seLinux`
The user ID	`runAsUser`
Configuring allowable supplemental groups	`supplementalGroups`
Allocating an FSGroup that owns the pod's volumes	`fsGroup`
Requiring the use of a read only root file system	`readOnlyRootFilesystem`
Running of a container that allow privilege escalation from its parent	`allowPrivilegeEscalation`
Control whether a process can gain more privileges than its parent process	`defaultAllowPrivilegeEscalation`
Whitelist of allowed host paths	`allowedHostPaths`
Whitelist of the flex volume drivers	`allowedFlexVolumes`

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:

Controlled by a Boolean: Fields of this type default to the most restrictive value.
Controlled by an allowable set: Fields of this type are checked against the set to ensure their values are allowed.
Controlled by a strategy: Items that have a strategy to provide a mechanism to generate the value and a mechanism to ensure that a specified value falls into the set of allowable values.

Strategies

RunAsUser

MustRunAs - Requires a range to be configured. Uses the first value of the range as the default. Validates against the configured range.
MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined in the image. No default provided.
RunAsAny - No default provided. Allows any runAsUser to be specified.

SELinux

MustRunAs - Requires seLinuxOptions to be configured if not using pre-allocated values. Uses seLinuxOptions as the default. Validates against seLinuxOptions.
RunAsAny - No default provided. Allows any seLinuxOptions to be specified.

SupplementalGroups

MustRunAs - Requires at least one range to be specified. Uses the minimum value of the first range as the default. Validates against all ranges.
RunAsAny - No default provided. Allows any supplementalGroups to be specified.

FSGroup

MustRunAs - Requires at least one range to be specified. Uses the minimum value of the first range as the default. Validates against the first ID in the first range.
RunAsAny - No default provided. Allows any fsGroup ID to be specified.

Controlling Volumes

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:

azureFile
azureDisk
flocker
flexVolume
hostPath
emptyDir
gcePersistentDisk
awsElasticBlockStore
gitRepo
secret
nfs
iscsi
glusterfs
persistentVolumeClaim
rbd
cinder
cephFS
downwardAPI
fc
configMap
vsphereVolume
quobyte
photonPersistentDisk
projected
portworxVolume
scaleIO
storageos
* (allow all volumes)

The recommended minimum set of allowed volumes for new PSPs are configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.

Host Network

HostPorts, default empty. List of HostPortRange, defined by min(inclusive) and max(inclusive), which define the allowed host ports.

AllowPrivilegeEscalation

Gates whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation=true. This field defaults to false.

DefaultAllowPrivilegeEscalation

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 nil allows privilege escalation so as to not break setuid binaries. Setting it to false ensures that no child process of a container can gain more privileges than its parent.

AllowedHostPaths

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 pathPrefix that defines a host path to match. The value cannot be "*" though. 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"

AllowedFlexVolumes

This specifies a whitelist of flex volume drivers that are allowed to be used by flexVolume. An empty list means there is no restriction on the drivers. Please make sure volumes contains the flexVolume volume type, no flex volume driver is allowed otherwise. For example:

apiVersion: extensions/v1beta1
kind: PodSecurityPolicy
metadata:
  name: allow-flex-volumes
spec:
  volumes:
  - flexVolume
  allowedFlexVolumes:
  - driver: example/lvm
  - driver: example/cifs

Admission

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:

Retrieve all PSPs available for use.
Generate field values for security context settings that were not specified on the request.
Validate the final settings against the available policies.

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.

Creating a Pod Security Policy

Here is an example Pod Security Policy. It has permissive settings for all fields

{% include code.html language="yaml" file="psp.yaml" ghlink="/docs/concepts/policy/psp.yaml" %}

Create the policy by downloading the example file and then running this command:

$ kubectl create -f ./psp.yaml
podsecuritypolicy "permissive" created

Getting a list of Pod Security Policies

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 projected]

Editing a Pod Security Policy

To modify policy interactively, use kubectl edit:

$ kubectl edit psp permissive

This command will open a default text editor where you will be able to modify policy.

Deleting a Pod Security Policy

Once you don't need a policy anymore, simply delete it with kubectl:

$ kubectl delete psp permissive
podsecuritypolicy "permissive" deleted

Enabling Pod Security Policies

In order to use Pod Security Policies in your cluster you must ensure the following

You have enabled the API type extensions/v1beta1/podsecuritypolicy (only for versions prior 1.6)
You have enabled the admission control plug-in PodSecurityPolicy
You have defined your policies

Working With RBAC

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.

12 KiB Raw Blame History