View Documentation Try Kubernetes

Reference Documentation

Design docs, concept definitions, and references for APIs and CLIs.

Edit This Page

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.

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:

  1. Running of privileged containers.
  2. Capabilities a container can request to be added.
  3. The SELinux context of the container.
  4. The user ID.
  5. The use of host namespaces and networking.
  6. Allocating an FSGroup that owns the pod’s volumes
  7. Configuring allowable supplemental groups
  8. Requiring the use of a read only root file system
  9. Controlling the usage of volume types

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:

Strategies

RunAsUser

SELinuxContext

SupplementalGroups

FSGroup

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:

  1. azureFile
  2. flocker
  3. flexVolume
  4. hostPath
  5. emptyDir
  6. gcePersistentDisk
  7. awsElasticBlockStore
  8. gitRepo
  9. secret
  10. nfs
  11. iscsi
  12. glusterfs
  13. persistentVolumeClaim
  14. rbd
  15. cinder
  16. cephFS
  17. downwardAPI
  18. fc
  19. configMap
  20. * (allow all volumes)

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

Admission

Admission control with PodSecurityPolicy allows for control over the creation of resources based on the capabilities allowed in the cluster.

Admission uses the following approach to create the final security context for the pod:

  1. Retrieve all PSPs available for use.
  2. Generate field values for security context settings that were not specified on the request.
  3. 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

psp.yaml
 
{
  "kind": "PodSecurityPolicy",
  "apiVersion":"extensions/v1beta1",
  "metadata": {
    "name": "permissive"
  },
  "spec": {
      "seLinux": {
          "rule": "RunAsAny"
      },
      "supplementalGroups": {
          "rule": "RunAsAny"
      },
      "runAsUser": {
          "rule": "RunAsAny"
      },
      "fsGroup": {
          "rule": "RunAsAny"
      },
      "volumes": ["*"]
  }
}

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

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

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

  1. You have enabled the api type extensions/v1beta1/podsecuritypolicy
  2. You have enabled the admission controller PodSecurityPolicy
  3. You have defined your policies

Analytics Create an Issue Edit this Page