Kyverno Policy as Code Cheat Sheet

Updated 2026-05-22

Next Topic: Microservices with Containers Cheat Sheet

Kyverno is a CNCF-graduated Kubernetes-native policy engine that runs as a dynamic admission controller, enforcing governance through declarative YAML policies — no new language required. It validates, mutates, generates, verifies images, and cleans up resources at the cluster level, solving the gap between raw Kubernetes RBAC and fine-grained operational governance. Where tools like OPA Gatekeeper require learning Rego, Kyverno policies read like familiar Kubernetes manifests, dramatically reducing the barrier to policy-as-code adoption. As of Kyverno 1.17 (January 2026), the modern CEL-based policy types (ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, DeletingPolicy) reached GA status, while the older ClusterPolicy/Policy JMESPath-based types were officially deprecated with removal planned for v1.20 (October 2026).

What This Cheat Sheet Covers

This topic spans 22 focused tables and 167 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Architecture and Core ConceptsTable 2: Policy Resource TypesTable 3: Validate Rules (Legacy ClusterPolicy)Table 4: Mutate Rules (Legacy ClusterPolicy)Table 5: Generate Rules (Legacy ClusterPolicy)Table 6: verifyImages Rules (Legacy ClusterPolicy)Table 7: Match and Exclude SelectorsTable 8: Variables and JMESPathTable 9: Policy ExceptionsTable 10: Policy ReportsTable 11: Background Scanning vs Admission ScanningTable 12: Auto-Generated Rules for Pod ControllersTable 13: Kyverno CLI and Local TestingTable 14: Policy Settings and Webhook ConfigurationTable 15: Installation, Helm Chart Deployment, and High AvailabilityTable 16: Observability and MetricsTable 17: Kyverno vs OPA GatekeeperTable 18: GitOps Policy Delivery with ArgoCDTable 19: Common Policy Patterns and Multi-TenancyTable 20: Troubleshooting KyvernoTable 21: Cleanup Policies and TTL LabelsTable 22: CEL-Based Policy Types (Modern — v1.17+)

Table 1: Architecture and Core Concepts

Kyverno integrates directly into the Kubernetes admission control pipeline via dynamic admission webhooks, making every resource create/update/delete event a policy evaluation opportunity. Understanding the four controllers and how they divide responsibility is the key to sizing, troubleshooting, and securing a production Kyverno installation.

Concept	Example	Description
Admission Controller	API Server → webhook → Kyverno Engine	Kyverno registers as a dynamic admission controller, receiving `AdmissionReview` requests from the Kubernetes API server via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration`.
Admission Controller (Kyverno)	`admissionController.replicas: 3`	• The main required controller • handles all webhook callbacks for validation, mutation, image verification, and policy exceptions
Background Controller	`backgroundController.replicas: 2`	Optional controller that processes generate and mutate-existing rules by reconciling `UpdateRequest` intermediary resources.
Reports Controller	`reportsController.replicas: 2`	Optional controller responsible for creating and reconciling PolicyReports and ClusterPolicyReports from intermediary admission and background scan reports.
Cleanup Controller	`cleanupController.replicas: 2`	Optional controller that handles scheduled CleanupPolicy and ClusterCleanupPolicy resource deletions.

Table 1: Architecture and Core Concepts

Concept	Example	Description
Admission Controller	API Server → webhook → Kyverno Engine	Kyverno registers as a dynamic admission controller, receiving `AdmissionReview` requests from the Kubernetes API server via `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration`.
Admission Controller (Kyverno)	`admissionController.replicas: 3`	• The main required controller • handles all webhook callbacks for validation, mutation, image verification, and policy exceptions
Background Controller	`backgroundController.replicas: 2`	Optional controller that processes generate and mutate-existing rules by reconciling `UpdateRequest` intermediary resources.
Reports Controller	`reportsController.replicas: 2`	Optional controller responsible for creating and reconciling PolicyReports and ClusterPolicyReports from intermediary admission and background scan reports.
Cleanup Controller	`cleanupController.replicas: 2`	Optional controller that handles scheduled CleanupPolicy and ClusterCleanupPolicy resource deletions.