Kubernetes Pod Security Standards: A Practical Guide

Pod Security Standards (PSS) replaced PodSecurityPolicies in Kubernetes 1.25. They define three levels of security restrictions for pods: Privileged, Baseline, and Restricted.

Why Pod Security Standards Matter

Running pods without security constraints is one of the most common Kubernetes misconfigurations. PSS gives you a built-in way to enforce security policies without third-party tools.

The Three Security Levels

Privileged

No restrictions. Use only for system-level workloads like CNI plugins or storage drivers.

Baseline

Prevents known privilege escalations. Good default for most workloads:

apiVersion: v1
kind: Namespace
metadata:
  name: my-app
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted

Restricted

Maximum security. Requires dropping all capabilities, running as non-root, and read-only root filesystem.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: myapp:latest
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop: ["ALL"]
        readOnlyRootFilesystem: true

Migration Strategy

1. Start by adding warn mode to existing namespaces
2. Review warnings in your cluster logs
3. Fix workloads that violate the policy
4. Switch from warn to enforce

FAQ

Can I use PSS alongside OPA/Gatekeeper? Yes. PSS handles the baseline, and OPA can enforce custom policies on top.

What happens to running pods when I enable enforce mode? Existing pods are not affected. Only new pods are checked at admission time.

Should I use Restricted for everything? Start with Baseline and move to Restricted where possible. Some workloads genuinely need elevated privileges.

Next Steps

Apply Baseline enforcement to your development namespaces first, then gradually roll out to staging and production.