Pod Security Admission: Kubernetes' Built-in Guardrails

WHY IT EXISTS: Kubernetes needed a simpler, more maintainable way to enforce basic pod security than the deprecated PodSecurityPolicy (PSP). PSP was powerful but overly complex and easy to misconfigure, often leading to either insecure clusters or broken workloads. PSA provides a standardized, out-of-the-box solution that is easier to reason about.

THE MENTAL MODEL: Think of PSA as a set of security "dress codes" for your Kubernetes namespaces. Each namespace can have a different code: Privileged (no rules), Baseline (business casual, prevents obvious risks), or Restricted (formal attire, very strict). The PSA admission controller acts as the bouncer, checking every new pod against its namespace's dress code before it's allowed in.

HOW IT WORKS: PSA is a built-in admission controller that's enabled by default in modern Kubernetes clusters. You configure it by applying labels to namespaces. For example, pod-security.kubernetes.io/enforce: baseline tells the controller to reject any pod in that namespace that doesn't meet the Baseline standard. You can also set modes for warn (log a warning but allow the pod) and audit (log the violation for later review). The controller intercepts pod creation requests and validates them against the policy defined by the namespace label.

WHEN TO USE IT: Use PSA to establish a baseline security posture across your cluster. It's ideal for preventing common misconfigurations and privilege escalation vectors in application namespaces. Applying the Baseline policy to all non-system namespaces is a standard best practice. Use the Restricted policy for namespaces running untrusted or multi-tenant workloads that require maximum hardening.

WHEN NOT TO USE IT: The Privileged level effectively disables PSA, and should only be used for highly trusted, system-level components that require deep host access, such as CNI plugins or storage drivers in the kube-system namespace. Avoid PSA if you need fine-grained policy control beyond the three predefined levels; for that, a third-party admission controller like Kyverno or OPA Gatekeeper is a better fit.

ONE CANONICAL EXAMPLE: To protect a namespace named app-staging from running insecure pods, you apply the Baseline policy. The command is: kubectl label --overwrite ns app-staging pod-security.kubernetes.io/enforce=baseline. Now, if a developer tries to deploy a pod with hostNetwork: true in that namespace, the API server will reject it with an error message explaining the violation.