Kyverno Policy as Code Cheat Sheet

Updated 2026-05-22

Next Topic: Microservices with Containers Cheat Sheet

🧠Study flashcards on this topic131 cards · spaced repetition→

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, 131 flashcards. 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+)

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

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.
Webhook Controller	Watches installed policies → updates webhook config	Dynamically configures the webhooks so the API server only forwards requests for resource kinds matched by installed policies, minimizing unnecessary traffic.
Cert Renewer	Watches/renews TLS Secrets	Watches and auto-renews the TLS certificates (stored as Kubernetes Secrets) needed for the webhook.
Fail-closed mode	`failurePolicy: Fail` (default)	• Default behavior: if Kyverno is unreachable, the API server blocks the request • ensures security-by-default but risks cluster inoperability if Kyverno namespace is not excluded
Fail-open mode	`failurePolicy: Ignore`	• If Kyverno webhook is unavailable, the request is allowed through • trades security for availability — recommended only for non-critical or optional policies
High Availability	`admissionController.replicas: 3`	• Production installs should run the admission controller with at least 3 replicas • minimum supported HA count for leader election and certificate management

Table 2: Policy Resource Types

Kyverno 1.17 introduced a new generation of CEL-based policy types under the policies.kyverno.io/v1 API group that reached stable (GA) status. The legacy ClusterPolicy/Policy types under kyverno.io/v1 are officially deprecated as of 1.17 and planned for removal in v1.20 (October 2026). New policies should use the modern CEL types.

Type	Example	Description
ValidatingPolicy	`apiVersion: policies.kyverno.io/v1` `kind: ValidatingPolicy`	• Modern CEL-based type • validates Kubernetes resources or JSON payloads using CEL expressions • GA in v1.17 under `policies.kyverno.io/v1`.

The rest of this section is part of the full cheat sheet

Table 3: Validate Rules (Legacy ClusterPolicy)

Validate rules are the most common policy type in legacy ClusterPolicy — they define required properties for Kubernetes resources and either block (Enforce) or record violations (Audit). Understanding patterns, deny rules, anchors, and the failureAction field covers the vast majority of real-world use cases.

Technique	Example	Description
pattern overlay	`pattern:` `metadata:` `labels:` `team: '?*'`	• The primary validation mechanism • Kyverno compares the resource against the pattern and fails if any specified field is missing or mismatched. `?*` means "any non-empty value."

The rest of this section is part of the full cheat sheet

Table 4: Mutate Rules (Legacy ClusterPolicy)

Mutate rules automatically modify resources at admission time, injecting defaults, annotations, or security contexts before resources are persisted. They are written as either strategic merge patches (overlay style) or RFC 6902 JSON patches, and run before validate rules.

Technique	Example	Description
strategic merge patch (overlay)	`mutate:` `patchStrategicMerge:` `spec:` `containers:` `- (name): '*'` `securityContext:` `readOnlyRootFilesystem: true`	• Most common mutation approach • merges fields into the resource like `kubectl patch` • uses Kyverno overlay with anchors for conditional logic

The rest of this section is part of the full cheat sheet

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.
Webhook Controller	Watches installed policies → updates webhook config	Dynamically configures the webhooks so the API server only forwards requests for resource kinds matched by installed policies, minimizing unnecessary traffic.
Cert Renewer	Watches/renews TLS Secrets	Watches and auto-renews the TLS certificates (stored as Kubernetes Secrets) needed for the webhook.
Fail-closed mode	`failurePolicy: Fail` (default)	• Default behavior: if Kyverno is unreachable, the API server blocks the request • ensures security-by-default but risks cluster inoperability if Kyverno namespace is not excluded
Fail-open mode	`failurePolicy: Ignore`	• If Kyverno webhook is unavailable, the request is allowed through • trades security for availability — recommended only for non-critical or optional policies
High Availability	`admissionController.replicas: 3`	• Production installs should run the admission controller with at least 3 replicas • minimum supported HA count for leader election and certificate management

Table 2: Policy Resource Types

Type	Example	Description
ValidatingPolicy	`apiVersion: policies.kyverno.io/v1` `kind: ValidatingPolicy`	• Modern CEL-based type • validates Kubernetes resources or JSON payloads using CEL expressions • GA in v1.17 under `policies.kyverno.io/v1`.

Table 3: Validate Rules (Legacy ClusterPolicy)

Technique	Example	Description
pattern overlay	`pattern:` `metadata:` `labels:` `team: '?*'`	• The primary validation mechanism • Kyverno compares the resource against the pattern and fails if any specified field is missing or mismatched. `?*` means "any non-empty value."

Table 4: Mutate Rules (Legacy ClusterPolicy)

Technique	Example	Description
strategic merge patch (overlay)	`mutate:` `patchStrategicMerge:` `spec:` `containers:` `- (name): '*'` `securityContext:` `readOnlyRootFilesystem: true`	• Most common mutation approach • merges fields into the resource like `kubectl patch` • uses Kyverno overlay with anchors for conditional logic