Kyverno: Kubernetes Policy as Code in YAML

Q: How do I test Kyverno policies?

With the Kyverno CLI in CI: kyverno apply evaluates policies against manifests, and kyverno test runs declared test cases with expected results.

Kyverno

Kubernetes accepts almost anything that is syntactically valid: containers running as root, Pods without resource limits, images from any registry, Services exposed to the internet by accident. Kyverno is a policy engine that runs as a Kubernetes admission controller and checks — or changes — resources as they are created and updated. Its policies are themselves Kubernetes resources written in YAML, so platform teams can express rules like "every container needs limits" or "images must be signed" without learning a separate policy language.

Kyverno can validate resources (reject or report violations), mutate them (add defaults), generate new resources (create a default NetworkPolicy in every namespace), and verify image signatures. Because it also scans existing resources in the background, it doubles as an audit tool for clusters that predate the policies.

TL;DR

Kyverno is policy as code in YAML, enforced by an admission webhook and background scans.
Rule types: validate, mutate, generate, and verifyImages.
Roll out new rules in Audit mode, read the policy reports, fix violations, then switch to Enforce.
Grant narrow, time-limited PolicyExceptions instead of weakening policies.
Test policies in CI with the Kyverno CLI against real manifests.
Start from the community policy library, and keep your own policies in Git.

Quick Example

Require CPU and memory limits on every container, reporting violations first:

Kyverno automatically extends Pod rules to Deployments, StatefulSets, Jobs, and other controllers, so violations are caught at the workload level. Once the reports are clean, change failureAction to Enforce. Older Kyverno versions set this as spec.validationFailureAction instead.

Core Concepts

Rule Types

Matching

Rules select resources with match and exclude blocks: kinds, namespaces, labels, and the users or groups making the request. Excluding system namespaces and platform service accounts prevents policies from blocking the cluster's own components.

Audit and Enforce

In Audit, violations are allowed but recorded in PolicyReport resources. In Enforce, admission requests that violate the rule are rejected with the policy's message. Background scanning keeps reports current for resources created before the policy existed.

Exceptions

A PolicyException exempts specific resources from specific rules — for example, a monitoring DaemonSet that legitimately needs host access. Exceptions live in a restricted namespace, are reviewed like code, and should carry an owner and an expiry date in their annotations.

More Rule Examples

Add a default runAsNonRoot when a Pod does not set it:

Create a default-deny NetworkPolicy in every new namespace:

A default-deny like this also blocks DNS; pair it with an allow rule for DNS in the same rollout.

Rolling Out Policies Safely

Write the policy in Git, with a test case for compliant and non-compliant manifests.
Test in CI with the Kyverno CLI against your application manifests (kyverno apply or kyverno test).
Deploy in Audit and review policy reports per namespace with the owning teams.
Fix or except: change manifests, or grant reviewed, time-limited exceptions.
Enforce once violations are gone, and keep background reports to catch drift.

Best Practices

Start From the Policy Library

The Kyverno project publishes a large library of tested policies, including the Kubernetes Pod Security Standards. Adapting them is faster and safer than writing everything from scratch.

Write Messages for the Person Who Is Blocked

A rejection message should say what is wrong and how to fix it: "Containers must set memory limits; see the platform guide on resource sizing." The message is often the only documentation a blocked engineer reads.

Protect the Platform From Itself

Exclude system namespaces and controllers where appropriate, set webhook failure behavior deliberately, and monitor Kyverno's own health. A broken admission controller can block every deployment in the cluster.

Verify Images in CI and at Admission

Sign images in CI and verify the signatures with verifyImages at admission, so only artifacts from your pipeline run in production. See Software Supply Chain Security.

Common Mistakes

Enforcing on Day One

Exceptions Without Owners or Expiry

Policies Tested Only in the Cluster

FAQ

What is Kyverno?

A Kubernetes-native policy engine that validates, mutates, and generates resources and verifies image signatures, using policies written as Kubernetes YAML resources and enforced through an admission webhook and background scans.

How does Kyverno compare with OPA Gatekeeper?

Both enforce admission policies. Kyverno policies are written in YAML with Kubernetes-style patterns and support mutation, generation, and image verification out of the box; Gatekeeper uses the Rego language from Open Policy Agent, which is more general and familiar to teams already using OPA elsewhere.

What is the difference between Audit and Enforce?

Audit lets violating resources through and records them in policy reports. Enforce rejects violating admission requests. Use Audit to measure impact before enforcing.

Can Kyverno fix existing resources?

Background scans report violations in existing resources, and mutate rules can be configured to update existing resources. Most teams fix manifests at the source in Git instead, so the change survives the next deployment.

How do I test Kyverno policies?

With the Kyverno CLI in CI: kyverno apply evaluates policies against manifests, and kyverno test runs declared test cases with expected results.