Lion Cipher Lab

Enforce Kubernetes policy at admission with Kyverno: make the API server itself refuse the bad Pod

• Cloud Security
• Advanced
• ~90 min
• Free · no account required

Why it matters

There is a specific moment that every policy-as-code programme eventually collides with, and it is worth picturing before you start. It is 2am. Something is down. An engineer with cluster credentials is on a bridge call, has been awake for nineteen hours, and types `kubectl apply -f fix.yaml` straight at production because the pipeline takes eleven minutes and the pipeline is not the point right now. That manifest never went near your CI. It never met Conftest, or Checkov, or a code review, or a second pair of eyes. It went directly from a tired person's laptop into your cluster — and…

What you'll learn

• how Kubernetes admission control actually works (the API server request path)
• installing and operating Kyverno on a local cluster
• writing a Kyverno ValidatingPolicy in CEL
• the Audit-then-Enforce rollout, and reading PolicyReport objects
• writing a MutatingPolicy that rewrites objects on their way in
• writing a GeneratingPolicy that creates resources for you
• PolicyException design, and the governance an exception needs
• choosing between Kyverno, OPA/Gatekeeper, Pod Security Admission and ValidatingAdmissionPolicy
• recognising the webhook failure modes that can wedge a cluster
• reading CEL (Common Expression Language) policy expressions

Steps in this lab

1. The 2am `kubectl apply` — why a pipeline check is not a control
2. The request path, and every single word in it
3. Build the throwaway cluster — and pin the node image, because the default one is too new
4. What Helm is, from zero — then install Kyverno with it
5. Look at what Kyverno just did to your cluster — the webhooks are real objects
6. The fork in the road: ClusterPolicy is on its way out, the CEL policy types are current
7. Enough CEL to write a real policy — and the field names that go around it
8. Ship it in AUDIT first — apply the bad Pod, watch it succeed, then read the PolicyReport
9. Flip to Deny — and read the exact refusal the API server hands back
10. The Deployment trap — why your policy 'stopped working' the moment you used a real workload
11. MutatingPolicy — the object comes back changed, and that is Kyverno's real differentiator
12. GeneratingPolicy — the third verb: create the thing that should have been there
13. PolicyException — because a policy nobody can override becomes a policy someone routes around
14. The judgment: Kyverno, Gatekeeper, Pod Security Admission, or the built-in ValidatingAdmissionPolicy — and when NOT to do any of this
15. Tear it down, and what you can now actually do

Open the full interactive lab →