About this scenario
The payments namespace must enforce the restricted Pod Security Standard: no root, no privilege escalation, no extra capabilities, a seccomp profile.
Pod Security Admission checks a namespace's Pods against the level in its pod-security.kubernetes.io/enforce label. Pods that break it are rejected, and a Deployment can't replace its Pods.
api and web run there today. Find what would break before you enforce, fix both, and keep web answering on its Service. Their manifests are in the editor.
Objectives
- See which Pods would break, before enforcing
- api meets the restricted standard
- web meets the restricted standard
- payments enforces restricted
- web still answers on its Service
What you'll practice
- Pod Security Admission is built in. A namespace label picks the level (
privileged, baseline, restricted) and the mode: enforce rejects Pods, warn and audit only report. - Enforcing never stops running Pods. It blocks new ones, so the next rollout or node failure is when things break. Dry-run the label first.
- Deployments are only warned about; their ReplicaSets then fail to create Pods (
FailedCreate). Always look at the ReplicaSet's events when a rollout makes no Pods. runAsNonRoot is checked by the kubelet against the image's user. Prefer images built to run as non-root over forcing a UID onto one that expects root.
How the playground works
The cluster runs entirely in your browser: a simulated API server, scheduler, kubelets and controllers, with virtual nodes in three zones. kubectl output follows the real formats, errors use the real messages, and the add-ons (CSI storage, Traefik, Envoy Gateway, cert-manager, Flux, Argo CD) behave like their real counterparts for the common paths. It's a simulation, so some behavior is simplified. Your progress is saved in this browser.