Kyverno can reject a workload or change what gets created
A Kubernetes workload can satisfy access controls and still violate your team's rules. Kyverno handles that second decision: it can reject a resource, change it, generate related resources, or clean resources up. The project README gives concrete uses such as requiring security contexts, adding labels, and generating NetworkPolicies. It's useful when the same rule needs to follow a workload across deployment tools, instead of depending on someone remembering a convention in each repository.
Our checkout held 9,736 files and about 385,963 lines of source in 43.5 MB. That's a substantial policy engine to contribute to, even before dependencies arrive. For a cluster operator, the important question is which of its functions you actually need. Validation alone is a narrower requirement than validation plus resource generation, image-signature verification, and continuing scans. Don't adopt every available controller merely because a complete installation example includes it.
What happened when we ran it
Our run installed Kyverno commit fe09190 in 97 seconds with 1,136 packages, built it in 457 seconds, and completed tests in 725 seconds. The go test summary recorded 284 passes and 0 failures out of 284. We ran the checkout on October 8, 2026. Installation, build, and the reported suite all succeeded, so this revision gave us a clean source-development result on the path our lab exercised.
The sandbox was a fresh, unprivileged Debian container using golang:1.24-bookworm, with 3 CPUs and 8 GB of RAM and no secrets. Those conditions make the result useful for comparing contributor setup. They don't establish admission latency, cluster recovery behavior, or the correctness of a policy you write tomorrow. No cluster-workload measurement is included in the supplied results. Keep those questions separate when deciding whether the clean suite is enough to proceed with a deployment trial.
Production setup includes webhooks and controller permissions
Kyverno's installation guide recommends Helm for production and requires a dedicated namespace. The admission controller receives callbacks from the API server, while other controllers handle background changes, reports, and cleanup. Installation also creates service accounts and their permissions, custom resource definitions, and secrets for webhook registration and API authentication. You'll need authority to install those cluster resources and a deployment configuration that matches the functions your policies use.
The 1,136 packages in our source install describe developer dependencies, not the number of running services or the size of a deployed image. Our build therefore doesn't price a production cluster for you. Check the supported Kubernetes release against the selected Kyverno release, choose controller availability, and confirm that the API server can reach the webhook service. Image verification may also require access to your chosen registry and its trust configuration. Treat those as deployment decisions beyond compiling the Go repository.
An unreachable fail-closed webhook can reject matching requests
The installation guide explains that resource webhooks default to configurable fail-closed behavior. If the API server cannot reach Kyverno for a resource matching a policy, that request fails. A rule that requires Pods to run as non-root can therefore affect Pod creation when the policy service is unavailable. This is the operating burden I'd examine first. Someone must own availability and recovery for a component that can interrupt ordinary deployment work.
A 725-second successful suite in our container doesn't answer whether your own namespace exclusions allow Kyverno to recover after an outage. The guide says its Helm defaults exclude Kyverno's namespace and describes the recovery risks when that protection is removed. Excluded namespaces also sit outside those webhook checks. Keep their access controlled through RBAC, document the exceptions, and rehearse recovery before broad enforcement. An exclusion is an explicit boundary of coverage, even when it helps the cluster restart.
RBAC and authored policies still define the protection
The README states that Kyverno complements Kubernetes RBAC and enforces only policies users define. It also explicitly excludes repairing flaws in Kubernetes itself or the underlying infrastructure. Those limits should shape the purchase decision: a policy engine can enforce a resource rule, but it can't supply an access-control design or infer every requirement you forgot to encode. I'd start with a specific recurring mistake, such as missing resource limits, and decide how the rule handles legitimate exceptions.
Our 284 passing tests give evidence about the repository's measured suite, not blanket approval for a copied policy library. Read each candidate against your actual resource shapes and responsibilities. The README also points to separate projects for reporting UI and service-mesh authorization, so core-engine adoption doesn't provide every surrounding interface. Budget for maintaining the rules as applications change. A policy that blocks a legitimate rollout still needs an owner who can explain and correct its behavior.
October activity shows maintenance, with a report-controller issue open
Our scan found 44 CI workflow files, a tests directory, and no Dockerfile. The last GitHub push was October 10, 2026, with 8,235 stars and 830 open issues and PRs. Release v1.19.1 shipped September 10. Issue 17035 reports an aggregate report-controller goroutine surviving controller shutdown on a development revision. A related fix remained in an open PR. That supports checking the reporting controller on your chosen version, rather than asserting that every stable installation has the defect. The push and current PR activity show ongoing work.
Gatekeeper and Kubewarden offer different policy approaches
Gatekeeper deserves a comparison if you already use its OPA-based constraint templates and want to retain that policy investment. Kubewarden evaluates policies compiled to WebAssembly and has separate runtime and audit components. I'd choose Kyverno when its resource mutation or generation directly solves the job and the platform team will operate the webhooks. Our 457-second source build is acceptable contributor overhead. The harder adoption requirement is naming who restores admission service when an unreachable webhook starts rejecting deployments.