Topic 34

Pod Security Standards

HardeningPolicy

The Pod Security Standards define three profiles — Privileged, Baseline, and Restricted — that constrain what a Pod is allowed to do. The built-in Pod Security Admission controller enforces them per namespace. Together they replaced PodSecurityPolicy, which was removed.

These controls limit the damage a compromised or misbehaving Pod can do: running as root, mounting the host filesystem, gaining extra capabilities. They are the baseline hardening that every production namespace should apply.

Why PodSecurityPolicy Was Removed

The old PodSecurityPolicy (PSP) was powerful but notoriously hard to use — its authorization model was confusing, ordering was unpredictable, and misconfiguration often blocked all Pods. It was deprecated and removed in Kubernetes 1.25. If you find documentation referencing PSP, it is obsolete; the replacement is Pod Security Admission with the Pod Security Standards.

The Three Profiles

Privileged is unrestricted — for trusted, system-level workloads only. Baseline blocks the known privilege-escalation paths (host namespaces, privileged containers, most hostPath) while staying broadly compatible with common apps. Restricted is the hardened profile: it additionally requires running as non-root, dropping all capabilities, a read-only root filesystem where feasible, and a seccomp profile. Restricted is the target for security-sensitive workloads.

Profile	Allows	Use for
Privileged	Everything — no restrictions	Trusted system components only
Baseline	Common apps; blocks known escalation paths	General workloads
Restricted	Hardened: non-root, no caps, seccomp	Security-sensitive workloads

Pod Security Admission

Enforcement is built into the API server and configured by labeling a namespace. Each namespace can set a profile for three modes: enforce (reject violating Pods), audit (record violations), and warn (return a warning to the user). Running audit and warn before flipping to enforce lets you see what would break without blocking anything.

Enforcing Restricted on a namespace

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

Gaps and Policy Engines

Pod Security Admission is intentionally simple: three fixed profiles applied per namespace, and that is all. It cannot express custom rules — "images only from our registry," "every Pod must have a team label," "these annotations are required." For anything beyond the three profiles you reach for a general policy engine (Topic 36): OPA/Gatekeeper or Kyverno. Use Pod Security Admission as the baseline and a policy engine for organization-specific rules.

PodSecurityPolicy (removed) vs Pod Security Admission

PodSecurityPolicy — the old mechanism — flexible but confusing and removed in 1.25. Do not build on it.

Pod Security Admission — built-in, label-driven enforcement of the three Pod Security Standards profiles. The current baseline.

Common Mistakes

Looking for PodSecurityPolicy — it was removed in 1.25; use Pod Security Admission.
Running workloads as root or with extra capabilities when Baseline or Restricted would do.
Flipping a namespace straight to enforce: restricted without first running audit/warn.
Assuming Pod Security Admission covers custom rules — it only applies the three fixed profiles.
Leaving namespaces with no profile, so nothing constrains what Pods may do.

Best Practices

Apply a Pod Security Standards profile to every namespace; aim for Restricted on sensitive ones.
Roll out with warn/audit first, then switch to enforce once clean.
Set the matching securityContext (non-root, drop capabilities, read-only root FS) in your Pods.
Add a policy engine for organization-specific rules the three profiles can't express.
Reserve the Privileged profile for genuinely trusted system components.

RelatedAdmission control & policy — policy engines for custom rules (Topic 36)Supply-chain security — restricting which images may run (Topic 37)securityContext — the per-Pod fields the profiles require

Knowledge Check

What replaced PodSecurityPolicy?

Pod Security Admission enforcing the three Pod Security Standards profiles
NetworkPolicy resources scoping which Pods may run a privileged security context
RBAC ClusterRoles that deny the privileged and runAsRoot verbs on Pods
The Cluster Autoscaler rejecting Pods that fail a security profile check

How is a Pod Security Standards profile applied to workloads?

By labeling the namespace with enforce/audit/warn modes and a profile
By annotating each Pod with the profile name and mode it should obey
Through a ClusterRole binding that maps the profile to a ServiceAccount
By editing the kubelet config on each node to set the enforced profile

What can Pod Security Admission NOT do?

Enforce custom organization rules like 'images only from our registry' — it only applies the three fixed profiles
Block privileged containers from being admitted into a labeled namespace
Require workloads to run as non-root by rejecting any Pod whose containers set runAsRoot or leave runAsNonRoot unset
Operate in audit mode and record violations without blocking the Pod

You got correct