Interactive Explainer

Relevant for:Mid-levelSeniorStaff

Why this matters at your level

Mid-level

Know the three PSS levels (privileged, baseline, restricted) and what each blocks. Understand how to label namespaces with pod-security.kubernetes.io/enforce.

Senior

Migrate clusters from PodSecurityPolicy (deprecated) to PodSecurity Admission. Use warn mode to identify violations before enforcing. Fix Helm charts and manifests that use dangerous fields.

Staff

Design namespace security tiers: restricted for application workloads, baseline for platform components, privileged only for explicitly approved system namespaces (kube-system). Enforce via Gatekeeper ConstraintTemplates for finer control beyond PSS three levels.

Pod Security Standards: Hardening Workload Configurations

Pod Security Standards define three security profiles (privileged, baseline, restricted) enforced at namespace level. They close the gap between RBAC permission to create pods and restrictions on what kinds of pods can be created.

~3 min read

Be the first to complete!

LIVEContainer Escape -- Privileged Pod -- Cryptominer Attack -- 2020

Breaking News

T-3w

Helm chart with privileged sidecar deployed by admin to production namespace

T+0

RCE exploited in main app container

T+5m

Attacker uses privileged sidecar + Docker socket to escape to host

T+15m

Cryptominer installed on host; SSH key added for persistence

T+3d

Anomalous CPU spike detected; incident response begins; pod security baseline enforced

—Cryptominer ran undetected

—From privileged sidecar via Docker socket

—The single field that enabled the escape

The question this raises

How does a privileged container escape to the host -- and what namespace-level control prevents privileged pods from being deployed regardless of who applies the Helm chart?

Test your assumption first

A namespace is labeled pod-security.kubernetes.io/enforce: baseline. A pod spec has privileged: false, hostPID: false, but requests the SYS_ADMIN capability. What happens?

Lesson outline

What Pod Security Standards Solve

The Privileged Pod Escape Path

A container with privileged: true or SYS_ADMIN capability can escape to the host -- mounting the host filesystem, seeing all host processes, loading kernel modules. Pod Security Standards enforce namespace-level restrictions on dangerous pod spec fields, preventing escape-enabling configurations from being deployed regardless of who applies them.

Privileged level

Use for: No restrictions. Required only for system components that genuinely need host access: CNI plugins (must configure host network), storage drivers (must access host block devices), node agents (must read host /proc). Use only in kube-system and dedicated system namespaces.

Baseline level

Use for: Blocks the most dangerous settings. All application namespaces should enforce at minimum baseline. Prevents: hostPID, hostNetwork, privileged containers, dangerous capabilities, hostPath mounts. Does not require non-root.

Restricted level

Use for: Full hardening: non-root required, no privilege escalation, seccomp profile required, drop all capabilities. Highest security. Breaks legacy charts. Use warn mode to identify violations first, then fix charts, then enforce.

The System View: What Each Level Blocks

Container Escape Techniques -> PSS Field that Enables -> Level that Blocks

privileged: true
  -> full host access (sysfs, /proc, all devs)
  -> baseline blocks: privileged: true

hostPID: true
  -> see/signal all host processes; nsenter host namespaces
  -> baseline blocks: hostPID: true

hostPath: /var/run/docker.sock
  -> Docker socket = create new containers with any config
  -> baseline blocks: hostPath volumes (most)

SYS_ADMIN capability
  -> mount filesystems, load kernel modules
  -> baseline blocks: SYS_ADMIN, SYS_PTRACE, NET_RAW, etc.

runAsUser: 0 (root in container)
  -> file UID 0; easier exploit of kernel vulns
  -> restricted blocks: runAsUser: 0, runAsNonRoot: false

allowPrivilegeEscalation: true (default!)
  -> child process can gain more privileges than parent
  -> restricted blocks: allowPrivilegeEscalation not explicitly false

Each dangerous field maps to a specific escape technique; PSS levels close these paths systematically

PSS Migration Strategy

Situation

Before

After

Cluster without pod security; privileged pods in production

“Any Helm chart can add privileged: true; developers may not know the risk; no enforcement at namespace level”

“Label namespaces with enforce: baseline; use warn: restricted to identify what needs fixing; fix charts; promote to restricted over 2 sprints”

Legacy app running as root (uid 0)

“Restricted PSS blocks it; rolling deployment fails; engineering blocked”

“Fix Dockerfile: USER 1000; add securityContext.runAsNonRoot: true to pod spec; test; enforce restricted on namespace”

How PSS Enforcement Works

Applying PSS to a namespace

→

1. Choose enforcement level: start with baseline for all prod namespaces

→

2. First apply warn mode: kubectl label ns production pod-security.kubernetes.io/warn=restricted

→

3. Deploy workloads normally; watch for PSS warning messages in kubectl output

→

4. Fix all violations (runAsRoot, missing seccomp, dangerous capabilities)

→

5. Switch to enforce: kubectl label ns production pod-security.kubernetes.io/enforce=baseline

6. For new namespaces, enforce at creation time via namespace template in GitOps

1. Choose enforcement level: start with baseline for all prod namespaces

2. First apply warn mode: kubectl label ns production pod-security.kubernetes.io/warn=restricted

3. Deploy workloads normally; watch for PSS warning messages in kubectl output

4. Fix all violations (runAsRoot, missing seccomp, dangerous capabilities)

5. Switch to enforce: kubectl label ns production pod-security.kubernetes.io/enforce=baseline

6. For new namespaces, enforce at creation time via namespace template in GitOps

pod-restricted-compliant.yaml

1spec:
2  securityContext:
Pod-level securityContext: applies to all containers in the pod
3    runAsNonRoot: true
4    runAsUser: 1000
5    seccompProfile:
6      type: RuntimeDefault
7  containers:
8  - name: app
9    image: myapp:v2
10    securityContext:
allowPrivilegeEscalation: false -- child processes cannot gain more privileges
11      allowPrivilegeEscalation: false
12      readOnlyRootFilesystem: true
13      capabilities:
drop: ALL -- removes all Linux capabilities; add back only what is needed
14        drop: ["ALL"]    # drop all capabilities
15    # No hostPID, hostNetwork, hostPath
16    # No privileged: true

What Breaks in Production: Blast Radius

PSS enforcement failure modes

Helm chart uses privileged sidecar — Many monitoring agents, log collectors, and storage drivers use privileged: true. Enforcing baseline without checking breaks these charts. Always run warn mode first to enumerate violations before enforcing.
System namespace locked down — Applying baseline or restricted to kube-system breaks CNI pods, storage drivers, and monitoring agents that need host access. Only apply privileged level to kube-system and dedicated infrastructure namespaces.
Image runs as root — Many base images (nginx, redis official) run as root (uid 0). Restricted PSS blocks runAsUser: 0. Requires Dockerfile fix: USER 1000 and correct file ownership. Cannot be fixed at pod spec level alone if image requires root.
No seccomp profile causes restricted rejection — Restricted PSS requires seccompProfile.type: RuntimeDefault or Localhost. Many older pod specs omit this field. Adding RuntimeDefault is safe -- it enables the container runtime default seccomp filter with minimal impact.

Pod running as root without privilege restrictions -- passes baseline, blocked by restricted

Bug

spec:
  containers:
  - name: app
    image: my-legacy-app:v1
    # runs as root (uid 0) inside container
    # no seccomp profile
    # no capabilities drop
    # allowPrivilegeEscalation defaults to true
    # passes baseline PSS but fails restricted

Fix

spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: my-legacy-app:v1-nonroot  # Dockerfile: USER 1000
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Restricted PSS requires all four: runAsNonRoot, explicit allowPrivilegeEscalation: false, seccompProfile, and dropping all capabilities. The image itself must support non-root (USER in Dockerfile). Cannot patch the image default user from pod spec alone.

Decision Guide: PSS Level Selection

Is this a system namespace (kube-system, CNI, storage drivers)?

YesUse privileged level -- system components need host access; apply strict RBAC + audit logging instead

NoApply at minimum baseline to all application namespaces

Are all workloads in this namespace running as non-root with no dangerous capabilities?

YesApply restricted level -- maximum security posture

NoApply baseline now; use warn: restricted to identify and fix violations; migrate to restricted

Are there Helm charts or legacy workloads you cannot immediately fix?

YesApply baseline enforce + restricted warn; track violations; fix in sprints before promoting to restricted enforce

NoApply restricted enforce directly after testing in staging

Cost and Complexity: PSS vs Custom Policies

Level	What it blocks	What still allowed	Migration effort	Recommended for
Privileged	Nothing	Everything	None	kube-system, CNI, storage drivers
Baseline	Container escape fields	Root containers, no seccomp	Low	All application namespaces minimum
Restricted	Root + escape + capabilities	Very little beyond defaults	Medium-high (fix charts)	New greenfield application namespaces
OPA/Gatekeeper custom	Whatever you specify	Whatever you allow	High (write Rego)	Finer-grained control beyond PSS three levels

Exam Answer vs. Production Reality

1 / 3

PSS three levels

📖 What the exam expects

Privileged: no restrictions (for system components like CNI, storage drivers). Baseline: blocks most dangerous settings (hostPID, hostNetwork, privileged, dangerous capabilities). Restricted: full hardening (no root, drop all capabilities, seccomp required).

Toggle between what certifications teach and what production actually requires

How this might come up in interviews

Security hardening design questions and container escape scenario discussions.

Common questions:

What are the three Pod Security Standard levels?
What pod spec fields enable container escapes?
How do you migrate from PodSecurityPolicy to Pod Security Admission?
How would you enforce pod security without breaking existing workloads?

Strong answer: Mentions using warn mode for gradual rollout, fixing Helm charts to pass restricted PSS, and Seccomp profiles as defense-in-depth beyond PSS restricted.

Red flags: Not knowing that privileged: true bypasses container isolation, or using PSP (removed in K8s 1.25).

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

Admission Controllers: The Policy Gateway

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning

Admission Controllers: The Policy Gateway

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord