Koray Oksay, a CNCF ambassador, believes that organizations often place Kyverno under the responsibility of security teams, using it to validate Kubernetes configurations, block containers running with root privileges, or enforce container security standards, and then leave much of its capabilities unused. According to Oksay's view, this mental classification confines Kyverno to the role of a “gate” that blocks bad configurations, whereas it can be used as a foundational building block on which platform teams build their services and operational rules.
This view is based on the author's experience, which began with a presentation at KCD Munich in 2023 titled “Securing Kubernetes Workloads with Kyverno.” After three years of working in production environments, he says his focus shifted to governance, CEL, and platform self-service, and that describing Kyverno as a “policy engine” is no longer sufficient to cover its scope.
Why Is the Security Classification Not Enough?
Oksay does not deny Kyverno's security functions. The platform can block insecure configurations, enforce Pod Security Standards, and validate container image signatures. However, linking it exclusively to security reinforces a model that views policy as a barrier whose primary purpose is rejection, with success measured by the number of deployments prevented.
By contrast, the author identifies four primary functions for Kyverno: validation, mutation, generation, and image verification. Validation belongs directly to the barrier model, while mutation changes resources before they are admitted to the cluster, generation creates new resources in response to specific events, and image verification focuses on building trust in images rather than merely blocking threats. He therefore argues that three of the four functions are constructive in nature, but many organizations use only validation policies.
What Does a Core Platform Component Mean?
Oksay uses the term “core component” in a sense close to its use in programming languages: a small, understandable building block that can be composed to build larger systems. For this building block to play an actual role in the platform, it should hide complexity from developers, provide automatic guarantees, integrate with other building blocks, and be available through self-service rather than relying on manual requests or support queues.
In this sense, Kyverno policies resemble components such as Pods, Services, ConfigMaps, and Crossplane compositions. They turn the rules adopted by an organization into automatic behavior within the platform.
How Do Platform Teams Use It?
- Preparing namespaces: When a namespace is created, Kyverno can generate default NetworkPolicy, ResourceQuota, LimitRange, and RoleBindings resources, so that the namespace appears ready without requiring developers to remember a list of manual steps.
- Injecting sidecar containers: Monitoring agents, network agents, or secret synchronization containers can be added to Pod specifications during the admission phase, while keeping the Deployment file simple.
- Rewriting image references: A reference such as nginx:1.25 can be converted to mirror.internal/nginx:1.25 so that pulls go through an internal mirror, rather than requiring every developer to add the prefix manually.
- Adding default resource requests: Instead of blocking Pods that do not specify CPU and memory requests, suitable values can be injected and adjusted when necessary.
- Assigning ownership labels: Team, cost-center, and environment labels can be added when the values are clear, or enforced when ambiguity has an impact.
What Changes in Practice?
These uses share one idea: turning an organizational principle into an invisible automated guarantee. The rule may be security-related, such as preventing containers with elevated privileges, operational, such as enforcing resource limits, or financial, such as associating every resource with a cost-center label. Instead of these rules remaining in a wiki, review checklists, or the knowledge of a single engineer, they become policy written as code, stored in Git, and applied through GitOps tools and Kyverno.
This perspective suggests treating policy as the platform's interface for expressing organizational intent. When applied, Kyverno's functions become different levels: validation provides guardrails, mutation lays out “paved roads” for developers, generation provides templates or initial provisioning, and image verification builds trust.
Teams will also treat policies as products with versions, users, retirement cycles, and traceable exceptions. Policy rollout can begin with auditing, followed by warnings, and then gradual enforcement. The author also points to potential coordination challenges when a policy modifies a resource that Argo CD or Flux considers itself to own, which could lead to synchronization loops.
Oksay's conclusion is that reading Kyverno solely as a security tool obscures a large part of its interface and capabilities. In his view, it is not a guard standing at the cluster entrance, but a layer that connects the platform team's views with the actual behavior of resources and applications.