mrvitej.in
Happy Dussehra! May good always win. Happy Diwali! Wishing you a bright year ahead. Merry Christmas! Warm wishes from Vizag. Happy New Year! Here’s to a great year ahead.

DevOps · CNCF daily

Kyverno: Kubernetes-Native Policy as Code

CNCF Graduated. A policy engine that validates, mutates, generates and cleans up Kubernetes resources, and verifies image signatures, using policies written in YAML or CEL instead of a separate policy language.

7 min read

CNCF Graduated

  • Kyverno
  • Kubernetes
  • Admission Control
  • Sigstore Cosign
  • Policy as Code
CNCF project page

Kyverno is a policy engine designed for Kubernetes. It runs as a dynamic admission controller and applies policies, written as Kubernetes resources, to every create, update and delete request. A policy can reject a resource, change it, generate related resources, check container image signatures, or clean up objects on a schedule. It addresses the need for platform and security teams to enforce standards without learning a separate policy language. Kyverno was created by Nirmata and joined the CNCF as a sandbox project in 2020. It reached incubating status in 2022 and graduated in March 2026. Its name comes from the Greek word for “to govern”.

CNCF daily · Sprint 2, day 6 · Security & Compliance

At a glance
Category Provisioning › Security & Compliance
CNCF status Graduated. Accepted November 10, 2020; incubating July 13, 2022; graduated March 16, 2026 (announced March 24, 2026)
Written in Go
License Apache 2.0
Policy languages YAML with pattern matching and JMESPath, and Common Expression Language (CEL) in the newer policy types
Policy actions Validate, mutate, generate, verify images, clean up
Delivery Admission controller in the cluster, CLI for CI pipelines, container image and SDK
Release rate Approximately monthly for patches and quarterly for minor releases, according to the project

Architecture

flowchart TB
  USER[kubectl and CI and GitOps] ==>|create or update| API[Kubernetes API server]
  API ==>|admission webhook call| ADM[Admission Controller<br/>validate mutate verify]
  ADM ==>|allow or deny| API
  POL[Policies and exceptions<br/>custom resources] ==>|loaded by| ADM
  POL ==>|loaded by| BG[Background Controller<br/>generate and mutate existing]
  BG ==>|creates or updates| RES[Cluster resources]
  ADM -.->|checks signatures| REG[Image registry and Cosign]
  ADM -.->|results| REP[Reports Controller<br/>PolicyReports]
  CLN[Cleanup Controller<br/>cleanup policies] ==>|deletes stale objects| RES
  CLI[Kyverno CLI in CI] -.->|tests policies and manifests| POL
  classDef actor fill:#eceff1,stroke:#455a64,stroke-width:1.5px,color:#1d1c1a
  classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
  classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
  classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
  classDef store fill:#fff3e0,stroke:#e65100,stroke-width:1.5px,color:#1d1c1a
  classDef sec fill:#fce4ec,stroke:#ad1457,stroke-width:1.5px,color:#1d1c1a
  classDef obs fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1d1c1a
  class USER actor
  class API ctrl
  class ADM,BG,CLN,CLI core
  class POL sec
  class RES data
  class REG store
  class REP obs

Key: teal blocks are the project itself, blue are cluster resources, purple are control and configuration, amber are storage and registries, red are security and policy, green are observability, grey are external actors. Thick arrows show the primary path, dashed arrows checks, results and tooling.

Component Responsibility
Admission Controller Receives webhook calls from the API server and applies validate, mutate and image verification rules before a resource is stored.
Background Controller Applies generate rules and mutates existing resources, and re-evaluates policies against objects that are already in the cluster.
Reports Controller Writes results into PolicyReport resources, which show which resources pass or fail each policy.
Cleanup Controller Deletes resources that match a cleanup policy, on a schedule or on a condition.
Policies and exceptions Kubernetes custom resources that hold the rules. A PolicyException lets named workloads skip a rule without weakening the rule for everyone.
Kyverno CLI Runs policies against manifests and test cases in a pipeline, so violations are found before deployment.

Design principle. Policy is data in the same form as the rest of the cluster configuration. Policies are Kubernetes resources, so they are stored in Git, reviewed, deployed by GitOps tools and tested in CI like any other manifest, and authors do not need to learn a separate language such as Rego.

Production reference design

A typical deployment is an EKS, GKE, AKS or on-premises cluster managed through GitOps.

  1. Plan for availability. The admission controller sits in the request path, so run it with several replicas and keep it off the nodes you cannot afford to lose.
  2. Install a pinned chart version with Helm: 
    helm repo add kyverno https://kyverno.github.io/kyverno/ && helm repo update
helm install kyverno kyverno/kyverno -n kyverno --create-namespace \
  --set admissionController.replicas=3
kubectl -n kyverno rollout status deploy/kyverno-admission-controller
  3. Start in audit mode. Deploy new policies with failureAction: Audit and read the PolicyReports. Switch to Enforce only after existing workloads comply or have approved exceptions.
  4. Apply a first guardrail that blocks the latest image tag: 
    apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata: { name: disallow-latest-tag }
spec:
  background: true
  rules:
    - name: require-pinned-image-tag
      match:
        any:
          - resources: { kinds: [Pod] }
      validate:
        failureAction: Audit
        message: "Images must use a pinned tag, not latest."
        pattern:
          spec:
            containers:
              - image: "*:*"
              - image: "!*:latest"
  5. Manage policies in Git. Keep policies in a repository, deploy them with Argo CD or Flux, and run kyverno test in the pipeline so a broken policy never reaches the cluster.

Typical uses include Pod Security Standards enforcement, required labels and resource limits, default network policies generated for new namespaces, and verifying that images are signed with Sigstore Cosign before they run.

Operational considerations

  • Availability and failure policy. If the webhook fails closed, an unavailable Kyverno can block deployments across the cluster. Run multiple replicas, set pod disruption budgets and decide deliberately between fail-open and fail-closed for each policy.
  • Scope the webhook. Exclude system namespaces and Kyverno’s own namespace from broad policies, and use match filters so the webhook is not called for resources that no policy needs.
  • Latency. Admission requests wait for the policy result. Keep policies simple, avoid slow external calls and measure webhook latency under load.
  • Exceptions and ownership. Use PolicyException with a defined owner and review date instead of loosening rules. Record who may create exceptions, because they can bypass a control.
  • Migration of policy types. Newer CEL-based policy types sit beside the original ClusterPolicy resource. Check the documentation for your version before choosing a type for new policies.

Adoption

  • The CNCF graduation announcement of March 2026 names Bloomberg, Coinbase, Deutsche Telekom, Groww, LinkedIn, Spotify, Vodafone and Wayfair as organisations that publicly rely on Kyverno.
  • In the same announcement, a LinkedIn engineer reported that Kyverno enforces policies across more than 230 clusters with over 500,000 nodes and handles more than 20,000 admission requests per minute.
  • Deutsche Telekom was also quoted in the announcement. The project reported its GitHub stars growing from 574 to more than 9,000.

Alternatives

Solution Model Best suited to
OPA Gatekeeper Admission controller using the Rego language and constraint templates Teams that already use OPA and want one policy language across Kubernetes and other systems
Kubernetes ValidatingAdmissionPolicy Built-in CEL rules evaluated inside the API server Simple validation rules with no extra components to run
Pod Security Admission Built-in enforcement of the Pod Security Standards Basic pod hardening without custom policy
Kubewarden Policies compiled to WebAssembly and run by an admission controller Teams that want to write policies in a general-purpose language

Strengths and limitations

Strengths Limitations
Policies are Kubernetes YAML, with no new language to learn The admission controller is in the request path, so outages or latency affect every deployment
Validate, mutate, generate, verify images and clean up in one tool Complex logic can become hard to read in YAML and JMESPath
Built-in PolicyReports and a CLI for testing in CI Several policy types and versions coexist, which needs care when choosing and migrating
Graduated project with a third-party security audit and a large adopter base Scoped to Kubernetes; teams wanting one engine for non-Kubernetes policy may prefer OPA
Good fit with GitOps workflows Broad policies and large clusters need sizing and tuning of the webhook

Recommendation

Adopt. Kyverno is a strong default policy engine for Kubernetes platform teams, especially when policy authors are cluster operators rather than specialists in a policy language. Begin in audit mode with a small set of high-value policies, run the admission controller with several replicas, and add enforcement gradually. If you need one policy language across Kubernetes and non-Kubernetes systems, evaluate OPA Gatekeeper as well.

References: CNCF project page · Kyverno documentation · Kyverno repository · CNCF graduation announcement · Kyverno policy library · CNCF Landscape

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.