Pod Security and Workload Hardening · Workload hardening

L7. Pod Security Standards: Restricted, Baseline and Privileged

Video generating

Check back soon for the video lesson on Pod Security Standards: Restricted, Baseline and Privileged

Pod Security Standards define three security profiles for pods. Learn how to enforce them with the built-in Pod Security Admission controller and when to use each level.

What Are Pod Security Standards?

Pod Security Standards (PSS) are a set of policies that define three levels of security for pods:

Level	Description	Use Case
Privileged	No restrictions	System-level workloads (CNI, storage drivers)
Baseline	Blocks known privilege escalations	General-purpose workloads
Restricted	Maximum hardening	Security-sensitive and untrusted workloads

The Three Levels in Detail

Privileged allows everything. Only use it for system pods that genuinely need host-level access (CNI plugins, storage drivers, monitoring agents that read /proc). Baseline blocks the most dangerous configurations:

No privileged containers
No hostNetwork, hostPID, or hostIPC
No host path volumes
Limited set of volume types
No adding dangerous capabilities like NET_RAW

Restricted adds further hardening:

Must run as non-root (runAsNonRoot: true)
Must drop ALL capabilities
Seccomp profile must be set to RuntimeDefault or Localhost
No privilege escalation (allowPrivilegeEscalation: false)
Must use a read-only root filesystem (recommended but not required)

Pod Security Admission Controller

The built-in Pod Security Admission (PSA) controller enforces these standards at the namespace level using labels:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Three modes control behavior:

enforce: Rejects pods that violate the policy
warn: Allows the pod but shows a warning to the user
audit: Allows the pod but logs a violation in the audit log

Best practice: Start with warn and audit on restricted to identify violations without breaking workloads. Switch to enforce once all pods comply.

Migration Strategy

Label all namespaces with warn: restricted and audit: restricted
Review warnings and audit logs to identify non-compliant pods
Fix workloads: add security contexts, drop capabilities, set runAsNonRoot
Switch to enforce: restricted or enforce: baseline per namespace
Grant privileged only to system namespaces (kube-system)

Version Pinning

Pin the PSS version to avoid surprises when you upgrade Kubernetes:

labels:
  pod-security.kubernetes.io/enforce: restricted
  pod-security.kubernetes.io/enforce-version: v1.31

Without a version pin, the policy automatically follows the latest Kubernetes version, which may add new restrictions that break existing workloads.

Exam Focus Points

✓Pod Security Standards define three levels: Privileged (no restrictions), Baseline (blocks known escalations), and Restricted (maximum hardening)
✓PSA is enforced at the namespace level using labels for enforce, warn, and audit modes
✓Restricted level requires runAsNonRoot, dropping ALL capabilities, seccomp profile, and no privilege escalation
✓Start migration with warn and audit modes before switching to enforce to avoid breaking workloads
✓Pin the PSS version in namespace labels to prevent unexpected policy changes during cluster upgrades

Knowledge Check

1. Which Pod Security Standard level requires containers to run as non-root?

2. What does the "warn" mode do in Pod Security Admission?

3. Why should you pin the Pod Security Standard version in namespace labels?

Service Account Hardening and Token Projection

Security Contexts: runAsNonRoot, Capabilities and Seccomp