Kyverno Turns Kubernetes Policy From a Security Gate Into a Platform Primitive

When platform teams evaluate Kyverno, they usually file it under security: run it past the security team, bundle it with a set of Pod Security Standard rules, and let it sit there quietly blocking the occasional root container. That is the category Koray Oksay, a CNCF Ambassador, says most organizations get wrong. In an August 19 CNCF Blog post that opens a new series on policy-driven platform engineering, Oksay argues that Kyverno is not a security tool that platform teams happen to use. It is a platform primitive: a building block on the same level as Pods and Services that also happens to be useful for security.

A Graduated Project Still Filed Under Security

Kyverno is a cloud native policy engine, originally built for Kubernetes and now usable outside clusters as a unified policy language, according to its official documentation. The name itself is Greek for “govern.” The Cloud Native Computing Foundation accepted the project on November 10, 2020, moved it to the Incubating maturity level in July 2022, and graduated it in March 2026, according to CNCF’s own project page. Its listed health metrics show real momentum: 3,838 contributors, up 26 percent year over year, across 1,081 contributing organizations, up 20 percent. Razorpay is cited in a CNCF case study for using Kyverno to help secure more than 7,000 Kubernetes nodes.

Oksay’s own history with the project traces the reframe he is now proposing. His first Kyverno conference talk, at KCD Munich in 2023, was titled “Securing Your Kubernetes Workloads with Kyverno,” filing the tool in the security drawer just like everyone else. Three years of production work later, he writes, his talks have shifted toward governance, CEL (Common Expression Language) policy authoring, and platform self-service, a shift he says reflects where the tool’s real value has moved.

Four Verbs, One Used Wall to Wall

The core of Oksay’s argument is about what “security tool” implies as a mental model: policy as a gate, deny as the primary verb, success measured in blocked deployments. Kyverno’s own documentation actually lists five policy types, covering validating, mutating, generating, deleting, and image-verifying resources, but Oksay compresses the argument to four working verbs: validate, mutate, generate, and verify container images. Only the first, he points out, fits the gate model. Mutation changes resources on their way into the cluster. Generation creates new resources in response to events. Image verification, using signing tools such as Sigstore or Notary, is about establishing trust more than blocking threats.

Three of four verbs are constructive rather than defensive, yet Oksay says most organizations deploy Kyverno with validation policies “wall to wall,” evaluated alongside OPA/Gatekeeper and scoped almost entirely to saying no. When the working mental model is policy equals deny, he argues, teams end up using roughly a quarter of what the tool can actually do.

What Platform Teams Actually Build With It

Oksay’s post walks through concrete examples of the other three verbs already running in production. A developer creates a namespace, and Kyverno’s generation rules automatically produce the default NetworkPolicy, ResourceQuota, LimitRange, and RoleBindings that would otherwise live on a wiki page nobody reads; the namespace simply shows up already furnished. Mutation rules inject sidecars, observability agents, service mesh proxies, and secret-sync containers directly into Pod specs at admission time, without a developer having to remember to declare any of them. Mutation rules can also silently rewrite image references, turning a plain nginx:1.25 tag into mirror.internal/nginx:1.25 so builds pull from an internal registry mirror instead of hitting Docker Hub’s rate limits.

None of that fits the description of blocking bad Pods. It is platform automation that happens to run through the same admission-control pipeline as security policy.

Policy as the Platform’s Intent, Not Its Documentation

The reframe Oksay lands on is that policy, expressed as code, is how a platform’s unwritten rules stop living in wikis, onboarding decks, and “that one senior engineer who reviews everything,” and start living in the system itself. Versioned in Git, delivered through GitOps tooling, and enforced by Kyverno, those rules become infrastructure instead of tribal knowledge. “Policy is the platform’s API for organizational intent,” he writes.

That reframe has a direct consequence for GitOps pipelines. If the policy repository matters as much as the application manifests it governs, tools like Argo CD or Flux are no longer just deploying workloads; they are deploying the rules that shape those workloads. Oksay flags, without fully resolving, a genuinely tricky wrinkle this creates: reconciliation conflicts when a Kyverno mutation changes a resource that a GitOps controller believes it owns outright. He says that tension will get its own post later in the series.

Read the Docs as an SDK, Not a Manual

Oksay’s closing advice is practical rather than theoretical: next time you are in the Kyverno docs, try reading them as a platform SDK instead of a security manual. He frames the tool’s capabilities as a rough hierarchy: validation is guardrails, mutation is paved roads, generation is scaffolding, and verification is trust. Most teams, in his telling, are only using the bottom layer.

That does not mean Kyverno’s security use case is wrong. Its validation rules genuinely block insecure configurations, enforce Pod Security Standards, and answer a CISO’s compliance questions, Oksay is careful to note. His argument is narrower: that treating Kyverno exclusively as a gatekeeper hides three-quarters of what a graduated CNCF project with thousands of contributors was actually built to do, and that the category mistake costs platform teams real leverage they are not spending.