Don't Panic — Kyverno

Kyverno is a policy engine that waits beside the Kubernetes API server and asks whether a resource request obeys the rules. Kubernetes is deliberately flexible. That is excellent until several teams can all submit YAML to the same cluster, at which point flexibility begins collecting paperwork and opinions.

The important route is short: a resource request reaches the API server, Kyverno receives the matching admission request, and a policy produces a result. A policy is a declarative Kubernetes resource that selects a target and states a condition or action. That selection is the part people underestimate. A policy that is correct for every Deployment is not helpful if it quietly also catches the controller request nobody intended to govern.

The policy types are verbs with a firm work ethic. A ValidatingPolicy checks a condition. A MutatingPolicy changes selected fields. A GeneratingPolicy creates or synchronizes a related resource. Cleanup policy types remove resources only when deletion is intentional and scoped. An ImageValidatingPolicy checks container images and metadata. The trick is choosing the outcome before choosing the syntax; otherwise the YAML begins driving the vehicle.

Kyverno can report results or enforce them. A policy report records matched resources and their status. It does not decide that a request should be blocked, repair an old resource, or settle anyone's acceptable risk. Nor does Kyverno replace Kubernetes authorization. Those are separate responsibilities, which is fortunate because one tool already has plenty of verbs.

Start with the Intro for the admission path and policy types. Use Slides when you want the map of choices. Keep the Cheatsheet nearby for scope and testing anchors. Then use the practice reference and exercise to test a passing and failing manifest with the CLI before a policy meets a live cluster.