Kyverno: A Detailed Way of Enforcing Standard and Custom Policies

In the Kubernetes ecosystem, security and governance are key aspects that need continuous attention. While Kubernetes offers some out-of-the-box (OOTB) security features such as Pod Security Admission (PSA), these might not be sufficient for complex environments with varying compliance requirements. This is where Kyverno comes into play, providing a powerful yet flexible solution for managing and enforcing policies across your cluster.

In this post, we will explore the key differences between Kyverno and PSA, explain how Kyverno can be used in different use cases, and show you how to install and deploy policies with it. Although custom policy creation will be covered in a separate post, we will reference some pre-built policies you can use right away.

What Is Kyverno?

Kyverno is a policy engine for Kubernetes that lets you validate, mutate and generate cluster resources using policies written as plain YAML — no new programming language required. It runs as an admission controller: when someone applies a resource, Kyverno intercepts the request and either allows it, rejects it, silently fixes it, or creates additional resources alongside it, according to the rules you have defined.

The name means “govern” in Greek, and that is a fair description of the job. Typical uses are enforcing that every pod sets resource limits, blocking images from untrusted registries, requiring specific labels on namespaces, automatically injecting a NetworkPolicy into every new namespace, or verifying image signatures before a workload is admitted.

Three properties are worth knowing before you evaluate it:

• Policies are Kubernetes resources. A Kyverno policy is a ClusterPolicy or Policy object written in YAML, so it goes through the same review, GitOps and RBAC machinery as the rest of your manifests.
• It does more than say no. Validation is only one of three modes. Kyverno can also mutate (patch a resource on the way in) and generate (create related resources automatically), which is where most of its day-to-day value ends up coming from.
• It is Kubernetes-only by design. That is a deliberate trade-off, and it is the main axis on which it differs from OPA Gatekeeper — see the comparison below.

The current release at the time of writing is Kyverno v1.18.2 (July 2026), and recent versions support both YAML-based and CEL-based policy expressions.

Kyverno vs OPA Gatekeeper: Which Policy Engine?

This is the comparison most teams actually need to make, and after several years of both projects converging it is rarely about raw capability. The short version: choose Kyverno if your policies are Kubernetes-only and you want them in YAML; choose OPA Gatekeeper if you need maximum expressiveness or want to reuse the same policy language outside Kubernetes.

There is now a third option that did not exist when this debate started: ValidatingAdmissionPolicy with CEL, built into Kubernetes itself. It needs no extra components at all, so if a rule can be expressed in CEL it is worth reaching for first. The limitation is that CEL cannot make external calls or hold state — so image-signature verification, cross-resource lookups, mutation and generation still belong to Kyverno or Gatekeeper. In practice many clusters end up with native CEL policies for the simple rules and Kyverno for everything else.

Who Maintains Kyverno? Governance and Commercial Support

Kyverno is a CNCF Graduated project — the same maturity tier as Kubernetes, Prometheus and Envoy, and the highest the foundation awards. That matters for the question every platform team eventually asks: the project is not owned by a single vendor who can change the licence, and graduation requires a demonstrated governance model, security audit and a healthy contributor base.

It was created by Nirmata, who remain the most active contributor and offer commercial support and long-term support around it. If you need a support contract, an LTS commitment or consulting, Nirmata is the primary vendor, and several others also provide commercial Kyverno support — Giant Swarm, InfraCloud, BlakYaks and Kodekloud among them. The open-source project itself is free and Apache-2.0, and nothing in the upstream distribution is gated behind a commercial tier.

What is Pod Security Admission (PSA)?

Kubernetes introduced Pod Security Admission (PSA) as a replacement for the now deprecated PodSecurityPolicy (PSP). PSA focuses on enforcing three predefined levels of security: Privileged, Baseline, and Restricted. These levels control what pods are allowed to run in a namespace based on their security context configurations.

• Privileged: Minimal restrictions, allowing privileged containers and host access.
• Baseline: Applies standard restrictions, disallowing privileged containers and limiting host access.
• Restricted: The strictest level, ensuring secure defaults and enforcing best practices for running containers.
  

While PSA is effective for basic security requirements, it lacks flexibility when enforcing fine-grained or custom policies. We have a full article covering this topic that you can read here.

Kyverno vs. PSA: Key Differences

Kyverno extends beyond the capabilities of PSA by offering more granular control and flexibility. Here’s how it compares:

1. Policy Types: While PSA focuses solely on security, Kyverno allows the creation of policies for validation, mutation, and generation of resources. This means you can modify or generate new resources, not just enforce security rules.
   
2. Customizability: Kyverno supports custom policies that can enforce your organization’s compliance requirements. You can write policies that govern specific resource types, such as ensuring that all deployments have certain labels or that container images come from a trusted registry.
   
3. Policy as Code: Kyverno policies are written in YAML, allowing for easy integration with CI/CD pipelines and GitOps workflows. This makes policy management declarative and version-controlled, which is not the case with PSA.
   
4. Audit and Reporting: With Kyverno, you can generate detailed audit logs and reports on policy violations, giving administrators a clear view of how policies are enforced and where violations occur. PSA lacks this built-in reporting capability.
   
5. Enforcement and Mutation: While PSA primarily enforces restrictions on pods, Kyverno allows not only validation of configurations but also modification of resources (mutation) when required. This adds an additional layer of flexibility, such as automatically adding annotations or labels.
   

When to Use Kyverno Over PSA

While PSA might be sufficient for simpler environments, Kyverno becomes a valuable tool in scenarios requiring:

• Custom Compliance Rules: For example, enforcing that all containers use a specific base image or restricting specific container capabilities across different environments.
• CI/CD Integrations: Kyverno can integrate into your CI/CD pipelines, ensuring that resources comply with organizational policies before they are deployed.
• Complex Governance: When managing large clusters with multiple teams, Kyverno’s policy hierarchy and scope allow for finer control over who can deploy what and how resources are configured.
  

If your organization needs a more robust and flexible security solution, Kyverno is a better fit compared to PSA’s more generic approach.

Installing Kyverno

To start using Kyverno, you’ll need to install it in your Kubernetes cluster. This is a straightforward process using Helm, which makes it easy to manage and update.

Step-by-Step Installation

Add the Kyverno Helm repository:

helm repo add kyverno https://kyverno.github.io/kyverno/

Update Helm repositories:

helm repo update

Install Kyverno in your Kubernetes cluster:

helm install kyverno kyverno/kyverno --namespace kyverno --create-namespace

Verify the installation:

kubectl get pods -n kyverno

After installation, Kyverno will begin enforcing policies across your cluster, but you’ll need to deploy some policies to get started.

Installing the Kyverno CLI

Separate from the in-cluster controller, Kyverno ships a CLI (kyverno) used to test and validate policies before they reach a cluster. It is the piece that makes policies reviewable in a pull request rather than discovered in production.

# macOS / Linux (Homebrew)
brew install kyverno

# Krew (as a kubectl plugin)
kubectl krew install kyverno

# Direct binary
curl -LO https://github.com/kyverno/kyverno/releases/latest/download/kyverno-cli_linux_x86_64.tar.gz
tar -xvf kyverno-cli_linux_x86_64.tar.gz && sudo mv kyverno /usr/local/bin/

The two commands worth knowing immediately:

# Apply a policy against manifests without touching a cluster
kyverno apply ./policies/ --resource ./manifests/

# Run the policy test suite defined in kyverno-test.yaml
kyverno test ./policies/

kyverno apply answers “would this policy have blocked this manifest?” and prints a policy report; kyverno test runs declarative test cases so policies have regression coverage like any other code. Wiring both into CI is covered step by step in integrating the Kyverno CLI into CI/CD pipelines with GitHub Actions.

The Kyverno Policy Library

Before writing anything yourself, check the official Kyverno policy library at kyverno.io/policies. It carries several hundred ready-made policies grouped by category — Pod Security Standards equivalents, best-practice rules, multi-tenancy controls, image verification, and cleanup policies. Most teams find that their first ten policies already exist there, and the realistic starting point is to adopt the Pod Security Standards set in audit mode, see what your cluster is already violating, and only then start writing custom rules.

Deploying Policies with Kyverno

Kyverno policies are written in YAML, just like Kubernetes resources, which makes them easy to read and manage. You can find several ready-to-use policies from the Kyverno Policy Library, or create your own to match your requirements.

Here is an example of a simple validation policy that ensures all pods use trusted container images from a specific registry:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-trusted-registry
spec:
  validationFailureAction: enforce
  rules:
  - name: check-registry
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Only images from 'myregistry.com' are allowed."
      pattern:
        spec:
          containers:
          - image: "myregistry.com/*"

This policy will automatically block the deployment of any pod that uses an image from a registry other than myregistry.com.

Applying the Policy

To apply the above policy, save it to a YAML file (e.g., trusted-registry-policy.yaml) and run the following command:

kubectl apply -f trusted-registry-policy.yaml

Once applied, Kyverno will enforce this policy across your cluster.

Viewing Kyverno Policy Reports

Kyverno generates detailed reports on policy violations, which are useful for audits and tracking policy compliance. To check the reports, you can use the following commands:

List all Kyverno policy reports:

kubectl get clusterpolicyreport

Describe a specific policy report to get more details:

kubectl describe clusterpolicyreport <report-name>

These reports can be integrated into your monitoring tools to trigger alerts when critical violations occur.

Frequently Asked Questions

Conclusion

Kyverno offers a flexible and powerful way to enforce policies in Kubernetes, making it an essential tool for organizations that need more than the basic capabilities provided by PSA. Whether you need to ensure compliance with internal security standards, automate resource modifications, or integrate policies into CI/CD pipelines, Kyverno’s extensive feature set makes it a go-to choice for Kubernetes governance.

For now, start with the out-of-the-box policies available in Kyverno’s library. In future posts, we’ll dive deeper into creating custom policies tailored to your specific needs.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.