Lion Cipher Lab

Enforce Kubernetes Pod Security Standards with the built-in Pod Security Admission

• Cloud Security
• Intermediate
• ~50 min
• Free · no account required

Why it matters

Hardening one pod with a securityContext is good; making sure nobody can deploy an un-hardened pod is what actually holds the line. A securityContext you have to remember to add is a securityContext someone eventually forgets — in a hurry, at 2am, in a copy-pasted manifest — and a single forgotten one quietly reintroduces a root, writable, over-privileged pod that an attacker who lands inside it can use as a launch pad toward the node and the rest of the cluster. Kubernetes ships a built-in answer that costs nothing to turn on: Pod Security Admission (PSA). It is an admission controller…

What you'll learn

• what Pod Security Admission (PSA) is: a built-in, GA-since-v1.25 admission controller that replaced the removed PodSecurityPolicy
• the three Pod Security Standards profiles — privileged (unrestricted), baseline (blocks known privilege escalations), restricted (heavily hardened, current pod-hardening best practice)
• the three PSA modes — enforce (reject the pod), audit (record in the audit log), warn (return a warning to the user) — and that they are set independently
• turning PSA on PER NAMESPACE with pod-security.kubernetes.io/<mode>=<profile> labels, and pinning the standard's version with the -version labels
• reading the real admission rejection that names exactly which restricted controls a pod violated (runAsNonRoot, allowPrivilegeEscalation, capabilities, seccompProfile)
• writing a pod spec that satisfies restricted and watching admission accept it
• rolling PSA out safely: warn/audit first to find what would break, then enforce — because restricted legitimately breaks some workloads
• judging when the built-in PSA is enough versus when you need a policy engine (Kyverno / OPA Gatekeeper) for custom rules, mutation, or per-workload exceptions

Steps in this lab

1. What Pod Security Admission is — built in, and the replacement for PodSecurityPolicy
2. The three profiles, and the three modes
3. Build the throwaway cluster (and pin the Kubernetes version)
4. Turn PSA on for a namespace — label it restricted (enforce + warn + audit)
5. Watch the API server REJECT a non-compliant pod
6. Watch a hardened pod get ADMITTED
7. The version caveat, and the safe rollout order
8. The judgment: when built-in PSA is enough, and when you need a policy engine

Open the full interactive lab →