Mastering Kubernetes PodSecurityPolicy: A Complete Guide to Secure Pods

Preface

PodSecurityPolicy objects control whether a pod can make certain requests and influence the SecurityContext applied to pods and containers.

What Is a Pod Security Policy?

A PodSecurityPolicy is a cluster‑level resource that defines a set of conditions a pod must satisfy to be accepted by the API server. It lets administrators restrict aspects such as user IDs, SELinux contexts, supplemental groups, file system groups, allowed volumes, host networking, and host paths.

RunAsUser

MustRunAs – Must specify a range; the first value in the range is used as the default.

MustRunAsNonRoot – Requires a non‑zero runAsUser value or an image‑defined USER environment variable; no default is provided.

RunAsAny – No default; any runAsUser value is allowed.

SELinux

MustRunAs – If no pre‑assigned value is used, seLinuxOptions must be set; defaults to the provided seLinuxOptions.

RunAsAny – No default; any seLinuxOptions ID is permitted.

SupplementalGroups

MustRunAs – At least one range is required; the smallest value of the first range is used as the default and all ranges are validated.

RunAsAny – No default; any supplementalGroups ID is allowed.

FSGroup

MustRunAs – Requires at least one range; the smallest value of the first range is used as the default and the first ID in that range is validated.

RunAsAny – No default; any fsGroup ID is allowed.

Volume Controls

By setting the volumes field in a PSP, you can restrict which volume types a pod may use. The full list includes:

azureFile

azureDisk

flocker

flexVolume

hostPath

emptyDir

gcePersistentDisk

awsElasticBlockStore

gitRepo

secret

nfs

iscsi

glusterfs

persistentVolumeClaim

rbd

cinder

cephFS

downwardAPI

fc

configMap

vsphereVolume

quobyte

projected

portworxVolume

scaleIO

storageos

* (allow all volumes)

For new PSPs, a minimal safe set of allowed volumes is recommended: configMap, downwardAPI, emptyDir, persistentVolumeClaim, secret, and projected.

Host Network

HostPorts are empty by default. HostPortRange defines allowed host ports using inclusive min and max values.

Allowed Host Paths

AllowedHostPaths

is a whitelist of permissible host‑path prefixes. An empty list means any host path is allowed.

Permissions

PodSecurityPolicy permissions control the creation and modification of cluster resources. The admission controller evaluates each field of a pod against the selected PSP; if all checks pass, the pod is accepted, otherwise it is rejected.

Creating a Policy and a Pod

Define a PSP in a YAML file. The example below disables privileged pods and uses permissive rules for most fields.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Don't allow privileged pods!
  # The rest fills in some required fields.
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
  - '*'

Apply the policy with:

kubectl-admin create -f example-psp.yaml

Listing PodSecurityPolicies

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           [*]

Modifying a PodSecurityPolicy

Use kubectl edit psp <name> to open the policy in your default editor and make changes.

Deleting a PodSecurityPolicy

kubectl delete psp permissive
podsecuritypolicy "permissive" deleted

Enabling PodSecurityPolicy in a Cluster

To use PSPs, ensure the following conditions are met:

The API type extensions/v1beta1/podsecuritypolicy is enabled (for versions prior to 1.6).

The PSP admission controller is enabled.

You have defined at least one PSP that matches your security requirements.