About this scenario
Production Deployments must pin their image tags and run at most 5 replicas. policy.yaml has a ValidatingAdmissionPolicy for that, checked by the API server with CEL, no webhook to run.
Its binding only warns for now, and it applies to every namespace. The dev namespace runs nginx:latest on purpose and must keep working.
Apply it, see what it warns about, limit it to namespaces labelled env=prod, then make it deny.
Objectives
- Apply the policy and see it warn
- The binding only covers namespaces labelled env=prod
- The binding denies, not just warns
- A :latest image is rejected in prod
- dev and prod keep running
What you'll practice
- A ValidatingAdmissionPolicy holds the rules in CEL; a binding decides where they apply and what happens when one fails:
Deny, Warn or Audit. - Start with
Warn (or Audit) to see what would break, then switch to Deny. - Policies only check requests. A Deployment that already breaks a rule keeps running until someone changes it.
- An image with no tag at all also means
:latest, which this expression misses. Test rules against the cases you care about, as you would code.
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.