Pod Security Standards define the minimum security requirements every pod in Kubernetes must follow. They enforce security boundaries around containers, ensuring workloads do not run with unnecessary privileges or dangerous capabilities. Pod Security Standards (PSS) replace PodSecurityPolicy and provide a simpler, more predictable model for enforcing pod-level hardening across clusters.

Understanding Pod Security Standards

PSS define three security levels:

• Privileged – No restrictions. Full host access allowed.
• Baseline – Blocks known risky configurations. Allows common workloads.
• Restricted – Strongest isolation. Enforces least privilege for zero-trust workloads.

These levels map directly to pod fields such as:

• capabilities
• privilege escalation
• host networking
• host path access
• volume types
• seccomp profiles
• SELinux/AppArmor settings
• user/group privileges

The API server applies these standards during admission.

Privileged Level

Privileged mode removes most restrictions. It allows:

• privileged containers
• host namespaces
• host networking
• hostPath volumes
• unsafe capabilities

It is used only for:

• system-level workloads
• CNI plugins
• storage drivers
• monitoring agents
• node-level controllers

Privileged workloads can break cluster isolation if misconfigured.

Baseline Level

Baseline prevents known insecure patterns but still supports common workloads. It blocks:

• privileged containers
• host namespaces
• host networking
• host ports
• unsafe sysctls
• adding dangerous capabilities
• hostPath volumes (with few exceptions)
• unrestricted file system access

Baseline is recommended for most application workloads.

Restricted Level

Restricted enforces:

• non-root containers
• read-only root filesystem
• least-privilege capabilities
• no privilege escalation
• seccomp profiles required
• no hostPath volumes
• no host namespaces
• safe volume types only
• minimal attack surface

Restricted is ideal for sensitive applications, regulated workloads, and zero-trust clusters.

Restricted moves pods closest to the hardened container security model.

How PSS Are Enforced

Kubernetes enforces Pod Security Standards using:

• Pod Security Admission (built-in)
• namespace labels
• policy evaluation at pod creation
• warnings + deny rules

The admission controller checks pod specs against the selected PSS level.

Example namespace labels:

pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/warn: baseline

This controls enforcement, logging, and warnings.

The PSS Enforcement Lifecycle

When a pod is created:

API server checks namespace labels
Admission controller validates pod spec
If configuration violates the standard:
• warn
• audit
• or reject
Create pod if valid

This ensures consistent, automated security.

Key Security Controls Checked by PSS

1. Privilege Escalation

Restricted and baseline block:

allowPrivilegeEscalation: true

2. Running as Root

Restricted enforces non-root users:

runAsNonRoot: true
runAsUser: 1000

3. Capabilities

Baseline blocks adding dangerous capabilities.
Restricted requires dropping all except minimal.

4. Host Namespaces

Restricted and baseline block:

• hostNetwork
• hostPID
• hostIPC

5. Volume Types

Restricted allows only safe types:

• configMap
• emptyDir
• projected
• secret
• downwardAPI
• persistentVolumeClaim

HostPath is blocked.

6. Seccomp

Restricted requires:

seccompProfile:
  type: RuntimeDefault

7. AppArmor / SELinux

Restricted encourages mandatory profiles.

Recommended Policy Layout

Use:

• cluster-wide restricted for sensitive namespaces
• baseline for general workloads
• privileged only for system namespaces like kube-system

This creates layered defense.

Full-Length Practical Section

Hands-on exercises to implement real PSS-based Kubernetes hardening.

Practical 1: View Current Namespace PSS

kubectl get ns --show-labels

Identify namespaces without PSS enforcement.

Practical 2: Apply Baseline Policy to a Namespace

kubectl label ns dev pod-security.kubernetes.io/enforce=baseline

Test pod creation.
Unsafe pods are rejected.

Practical 3: Apply Restricted Policy

kubectl label ns secure pod-security.kubernetes.io/enforce=restricted

Workloads must be fully hardened.

Practical 4: Create a Restriction-Violating Pod

kubectl run test --image=ubuntu -- bash -c "sleep 9999" \
  --overrides='{"spec":{"securityContext":{"runAsUser":0}}}'

Admission will deny pod under restricted namespace.

Practical 5: Test Baseline Pod With Extra Capabilities

kubectl run test --image=alpine \
  --overrides='{"spec":{"containers":[{"name":"c","image":"alpine","securityContext":{"capabilities":{"add":["SYS_ADMIN"]}}}]}}'

Baseline blocks SYS_ADMIN.

Practical 6: Verify Non-Root Behavior

Create restricted pod:

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
spec:
  securityContext:
    runAsNonRoot: true
  containers:
    - name: app
      image: alpine
      securityContext:
        allowPrivilegeEscalation: false

Check logs to confirm compliance.

Practical 7: Create Pod With Seccomp Profile

securityContext:
  seccompProfile:
    type: RuntimeDefault

Verify pod starts in restricted namespace.

Practical 8: Block HostPath Usage

Create pod using hostPath.
Restricted namespace rejects it.

Practical 9: Add PSS Warnings Only

kubectl label ns test pod-security.kubernetes.io/warn=restricted

Pods generate warning messages but still deploy.

Practical 10: Add PSS Audit Logging

kubectl label ns test pod-security.kubernetes.io/audit=baseline

Policy violations appear in audit logs.

Practical 11: Enforce Policies on CI/CD Namespaces

Apply baseline or restricted on namespaces used by pipelines.

Practical 12: Harden DaemonSet Workloads

DaemonSets often require privileged mode.
Create separate namespace with:

enforce=privileged

Practical 13: Validate Pod YAML Against PSS Before Deployment

Test locally:

kubectl apply --dry-run=server -f pod.yaml

Admission controller runs checks.

Practical 14: Build Restricted Deployment

runAsNonRoot: true
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false
capabilities:
  drop: ["ALL"]

Test under restricted namespace.

Practical 15: Test Insecure Pod for Learning

Try privileged container:

securityContext:
  privileged: true

Observe rejection.

Practical 16: Test Host Networking Block

hostNetwork: true

Rejected under baseline and restricted.

Practical 17: Use Cilium/Calico Synergy With PSS

Combine:

• PSS for container restrictions
• NetworkPolicies for traffic control

Practical 18: Combine PSS With RBAC

Assign access so only privileged operators can deploy workloads requiring elevated rights.

Practical 19: Validate PSS Violations With Events

Check:

kubectl describe pod <pod>

Admission events explain why pod was denied.

Practical 20: Build Complete Pod Security Hardening Layout

Architecture:

• restricted for production workloads
• baseline for development workloads
• privileged for kube-system
• RBAC for identity control
• NetworkPolicies for traffic segmentation
• Seccomp + AppArmor + capabilities hardening
• admission logs + audit logs
• CI validation before deployment

This provides comprehensive pod-level isolation.

Intel Dump

• Pod Security Standards include privileged, baseline, and restricted levels
• enforced using namespace labels and admission controller
• restricted level forces non-root, no privilege escalation, safe volumes, seccomp, and dropped capabilities
• baseline blocks risky patterns but supports common workloads
• practicals covered namespace labeling, denial testing, non-root pods, seccomp usage, host restrictions, and complete pod hardening architecture