Kyverno

Kyverno is a Kubernetes-native policy engine for platform teams that need to codify security, compliance, automation, and governance. Its range of policy actions and pre-deployment CLI testing is a strong combination; the trade-off is that it must run in a Kubernetes cluster and its default fail-closed webhooks require operational care.

Overview

Kyverno lets teams define policy as code using Kubernetes-style rules, with support for CEL-based policy types and a stated goal of extending that style of policy beyond Kubernetes. It is open source under the Apache License 2.0, and the CNCF records it as a Graduated project, with graduation in March 2026. The project also documents a 2023 third-party security audit and security assessments as part of its graduation process. These are useful project-level signals for teams assessing governance, but they do not replace evaluating how the software fits a particular cluster.

Key features

Enforcement and resource automation

Kyverno’s stable policy types can validate, mutate, generate, and delete resources, as well as verify container image signatures and attestations. That breadth suits teams that want policy to govern both admission decisions and resource workflows; teams seeking only a narrow validation check may not need the full range.

Pre-deployment testing

The Kyverno CLI can test policies in CI pipelines against Kubernetes resource manifests before they reach a live cluster. This gives teams a way to catch policy problems earlier in their delivery workflow, rather than relying solely on admission-time decisions.

Workflow integration

Kyverno’s documentation covers Helm, YAML manifests, GitHub Actions, and GitOps tools such as ArgoCD. That makes it relevant to teams already managing Kubernetes resources through those workflows, without requiring policy work to be detached from their delivery process.

Installation and operations

Kyverno runs inside a Kubernetes cluster. Helm is recommended for production, though YAML manifests are also available. A standard installation requires the admission controller; background, reports, and cleanup controllers are optional. Production installations should use high availability mode.

Resource webhooks default to fail-closed. If the API server cannot reach Kyverno, matching resource requests can fail, so teams should account for Kyverno availability in cluster operations rather than treating it as a noncritical add-on. The documentation marks legacy ClusterPolicy and CleanupPolicy types deprecated in v1.19 and scheduled for removal in v1.20; teams using those types should plan migration.

For image and manifest security, the project documents Cosign signatures. Its release artifacts include CLI binaries for Linux, macOS, and Windows. Users can seek support and discussion through the project’s Kubernetes Slack channels, GitHub, and mailing list.

Pricing

Kyverno costs nothing under the Kyverno plan. It is an open-source project under the Apache License 2.0, with no paid tier described. This fits teams able to install and operate the software themselves; Kyverno is self-hosted and requires a Kubernetes cluster, so it is not a hosted service for readers seeking managed deployment.

Platforms

Kyverno is self-hosted and installed in a Kubernetes cluster. Its platform coverage includes API, Linux, macOS, and Windows; the project lists CLI binaries for the three desktop operating systems, while policy enforcement itself depends on the cluster deployment.

Who it's for

Kyverno is best suited to platform engineering teams that need consistent policy enforcement across Kubernetes resources and want to connect security, compliance, governance, and automation to existing CI or GitOps workflows. It is less suitable for teams without Kubernetes operations capacity or those that cannot accommodate the availability implications of fail-closed admission webhooks.

Pros and cons

• Pros: One policy engine supports validation, mutation, generation, deletion, and image signature and attestation verification, covering more than admission checks alone.
• Pros: CLI testing against manifests can surface policy issues in CI before resources are applied to a live cluster.
• Pros: Helm, YAML, GitHub Actions, and ArgoCD are covered in the project documentation, supporting several common Kubernetes delivery workflows.
• Cons: Kyverno must be installed in a Kubernetes cluster, which rules it out for teams looking for a standalone or hosted policy service.
• Cons: Fail-closed webhooks can block matching requests when the API server cannot reach Kyverno, making availability planning important.
• Cons: Deprecated legacy policy types require migration planning for users who rely on them.

Alternatives

Kubescape is another free, Apache 2.0 option with a self-hosted CLI and Kubernetes operator, suited to readers comparing open-source Kubernetes security tools.

Monokle offers a free, open-source desktop application for Linux, macOS, and Windows; consider it when a desktop tool is a better fit than a cluster-installed policy engine.

KSPM Pro has a free plan for one Kubernetes cluster with real-time scans and CIS coverage, making it an option for readers whose needs center on that stated cluster-scanning offer.

Falco is a free, open-source option for Linux and self-hosted environments; compare it when those platform requirements match your needs.

KubeLinter is a free Apache 2.0 option for Linux, macOS, and self-hosted use, with no paid tiers listed.

Red Hat Trusted Artifact Signer is a paid alternative for Linux, macOS, self-hosted, web, and Windows environments.

Kubewarden is another free option with Linux, macOS, self-hosted, and Windows support.

Sysdig Secure is a paid alternative spanning API, Linux, macOS, self-hosted, web, and Windows, with licensing based on the number of hosts for its CSPM offering.

Explore more in Kubernetes Security Software, Cloud Governance Software, Container Security Software, Infrastructure as Code Security Software, and Infrastructure Policy as Code Tools.

Verdict

Choose Kyverno if your platform team wants Kubernetes-native policy with broad enforcement and automation actions, plus a way to test policies in CI before deployment. Its open-source price is compelling, but the cluster requirement and fail-closed webhook behavior make operational readiness the deciding factor; teams unable to own that responsibility should look elsewhere.