Kyverno
Kubernetes-native policy engine for validating, mutating, and generating Kubernetes resources. Kyverno policies are written in YAML (not Rego/OPA) — no new policy language to learn. Runs as a Kubernetes admission controller: blocks non-compliant resources at deployment time, auto-remediates existing resources, and generates new resources based on triggers. CNCF graduated. Powers policy enforcement for security (no root containers), compliance (required labels), and operational standards (resource limits) in Kubernetes clusters.
Score Breakdown
⚙ Agent Friendliness
🔒 Security
Apache 2.0 CNCF graduated with strong security posture. Kubernetes RBAC controls all policy management. Cosign image verification for supply chain security. Admission control enforces security at deployment time. Regular security audits as CNCF graduated project. No network API — Kubernetes admission webhook only.
⚡ Reliability
Best When
You need Kubernetes admission control and policy enforcement without learning Rego — Kyverno's YAML-based policies are accessible to platform engineers who know Kubernetes.
Avoid When
You need policy enforcement across multiple systems beyond Kubernetes — OPA provides broader policy enforcement beyond K8s admission control.
Use Cases
- • Enforce security policies for agent workloads in Kubernetes — block containers running as root, require non-privileged containers, and enforce read-only filesystems via Kyverno admission policies
- • Automatically mutate agent pod specs at admission time — inject sidecar containers, add resource limits, or set security contexts without modifying agent application manifests
- • Generate Kubernetes resources automatically when namespaces are created — provision network policies, resource quotas, and RBAC for each new agent namespace via Kyverno generators
- • Audit existing cluster resources for policy compliance via Kyverno's policy report API — agent compliance pipelines can query ClusterPolicyReport CRDs for violation summaries
- • Implement supply chain security policies — require signed container images via Kyverno's image verification with cosign before allowing deployment to agent environments
Not For
- • Application-level authorization — Kyverno controls Kubernetes resource admission, not application API authorization; use OPA, Cerbos, or Aserto for application-level authz
- • Non-Kubernetes policy enforcement — Kyverno is Kubernetes-specific; use OPA/Rego for general-purpose policy enforcement across services
- • Runtime threat detection — Kyverno enforces admission policies (before deployment), not runtime security; use Falco or Tetragon for runtime threat detection
Interface
Authentication
Kyverno interacts via Kubernetes API (RBAC). Kubernetes ServiceAccount tokens authenticate API calls. ClusterPolicyReport and PolicyReport CRDs are read via standard Kubernetes RBAC. No separate Kyverno authentication.
Pricing
Apache 2.0 CNCF graduated project. Completely free. Nirmata provides commercial support and enterprise features (Policy Manager UI, FIPS compliance). Free to use at any scale.
Agent Metadata
Known Gotchas
- ⚠ Kyverno policies run as admission webhooks — misconfigured Kyverno can block ALL resource creation in a cluster if webhook fails closed; always configure failurePolicy: Ignore during initial testing
- ⚠ Policy evaluation order matters for mutating policies — multiple mutating policies can conflict; use Kyverno's policy ordering configuration to control evaluation sequence
- ⚠ Image verification policies (cosign) add significant latency to pod creation — each image must be verified against a transparency log; budget 1-5 seconds of additional pod creation time
- ⚠ Generate policies (resource generation) are eventually consistent — generated resources (like NetworkPolicies for new namespaces) may not exist immediately after namespace creation
- ⚠ Kyverno's background scanning for existing resources (audit mode) runs periodically — violations for pre-existing non-compliant resources appear in PolicyReports only after background scan completes
- ⚠ Agent workflows that programmatically create Kubernetes resources must handle Kyverno admission rejections (400/422 errors) — implement retry with exponential backoff and log violation reasons for debugging
- ⚠ Policy testing with `kyverno test` requires test YAML files — agent CI pipelines validating Kyverno policies must maintain separate test resource fixtures alongside policy definitions
Alternatives
Full Evaluation Report
Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for Kyverno.
Scores are editorial opinions as of 2026-03-06.