Policy as Code for Regulated Teams: OPA & Kyverno

An AI coding assistant wrote a Kubernetes manifest. It was confident, well formatted, and every individual line in it was defensible. It also broke seven separate policies — and no amount of asking nicely in a system prompt makes that reliably stop happening. This is a live build on two real clusters, one running OPA Gatekeeper and one running Kyverno, breaking things against both so you can see the difference rather than read about it. Nothing on screen is a mock-up: the slides are generated from the policy files actually loaded on the clusters, and every verdict comes back from a real admission webhook. The through-line: a wiki page, a PR checklist and a line in your system prompt are all advisory controls. They ask. An admission webhook decides, and it is indifferent to who — or what — wrote the YAML. Chapters 0:00 Who I am, and what this hour is not 2:13 Policy as code for regulated teams 3:40 Both clusters said no 5:13 Azure Policy, and remembering Puppet 6:03 Advisory controls vs structural controls 8:01 Why it matters when you are regulated 8:53 OPA does not know what Kubernetes is 9:54 Gatekeeper: Rego wrapped in CRDs 11:36 Kyverno: Kubernetes-first 13:50 One rule, two languages: privileged 16:33 Required labels: 11 lines vs 8 21:23 The demo: seven ways to break a cluster 22:33 #1 A privileged container 24:09 #2 Missing owner labels 26:11 #3 The mutable latest tag 27:31 #4 An untrusted registry 29:16 #5 No resource limits 30:35 #6 A hostPath mount 31:53 #7 Host network and PID namespace 32:45 Audit mode: nobody turns policy on like that 35:29 Mutation: fix it instead of refusing it 36:19 Generation: the NetworkPolicy that comes back 37:37 Image signatures: signed vs unsigned 38:46 The caveat: CEL and validating admission policy 40:12 One rule, three languages 41:10 The question nobody asks: fail open or closed? 43:36 So which one? 45:49 Do not spend three months choosing 46:08 Back where we started 47:27 Book a discovery call The one thing worth doing this afternoon: go and look at your admission webhook configuration and find out whether it fails open or closed. Gatekeeper ships failurePolicy: Ignore with a 3 second timeout. Kyverno ships failurePolicy: Fail with 10 seconds. Neither default is wrong — fail-open protects the cluster, fail-closed protects the policy — but if you are regulated, "during the window your policy engine was unavailable, what got admitted?" is a specific, answerable question. Last week's livestream, on proving your software supply chain with Sigstore and SLSA — referenced throughout this one: https://youtu.be/9B7TNdiCWuU Open Policy Agent: https://openpolicyagent.org — CNCF graduated, 2021 Kyverno: https://kyverno.io — CNCF graduated, March 2026 Heads-up: Kyverno's ClusterPolicy type is deprecated. 1.19 warns on every apply, and 1.20 removes it. Tom Barber: https://linkedin.com/in/tombarber Want this properly assessed for your estate — which rules you actually need, which engine suits you, what your failure mode is today, and what it would take to get from audit to enforce without breaking every deploy in the building? That is what a discovery call is for. It is free, and it comes to me rather than to a form. https://concepttocloud.com — or tom@concepttocloud.com Concept To Cloud builds production data and compliance platforms for regulated, data-heavy organisations. #kubernetes #policyascode #opa #kyverno #platformengineering #devsecops