Kyverno sits on the security budget line, and three of its four verbs go unused

A post on the CNCF blog argues that Kyverno has been filed in the wrong drawer: it is evaluated alongside OPA/Gatekeeper, approved by the security team, deployed with a bundle of Pod Security Standard policies, and then mostly sits there blocking the occasional root container [s1c1][s1c2]. That matters because ownership is budgetary before it is technical, and the author's opening question is not which cluster Kyverno runs in but whose budget line it appears on [s1c1].

The mechanism is worth spelling out. "Security tool" carries a specific model with it, according to the post: policy as a gate, the primary verb is deny, and success is measured in blocked deployments [s1c3]. Kyverno does four things: validate, mutate, generate, verify images [s1c4]. Only validation fits the gate model [s1c5]. Mutation changes resources on their way into the cluster, generation creates new resources in response to things happening, and image verification is about establishing trust rather than blocking threats [s1c6]. Three of the four verbs are constructive [s1c7]. Yet the post's observation is that most organisations deploy validation policies wall to wall, which means using about a quarter of the tool [s1c8] - a rollout that exercises one capability out of four ^[1].

This is the part that should interest anyone who has watched a tool get procured by one team and used by another. If the owning team's success metric is blocked deployments [s1c3], then a cluster full of validation policies reports as a completed project. Nothing in that reporting line asks for generation or mutation work, so nothing funds it.

The returns, per the post, show up where platform teams pick the tool up. Namespace furnishing: a developer creates a namespace and Kyverno generates the default NetworkPolicy, ResourceQuota, LimitRange, RoleBindings and others, so the namespace arrives furnished instead of accompanied by a wiki page listing six things to remember [s1c9]. Sidecar injection: observability agents, mesh proxies and secret sync containers get mutated into Pod specs at admission, leaving the developer's Deployment manifest boring while the platform's requirements are still met [s1c10]. Image reference rewriting, so that images are pulled through an internal mirror [s1c11]. None of those are gates. They are governance and self-service, and they line up with the four properties the author sets for a platform primitive: it abstracts complexity, it provides guarantees, it composes, and you get it from the platform rather than a ticket queue [s1c12]. On that test the post puts Kyverno policies in the same category as Pods, Services, ConfigMaps and Crossplane compositions [s1c13].

Two honest caveats. First, this is one practitioner's argument, drawn from companies the author has talked to [s1c1], with no adoption or cost figures attached. Second, the author is describing their own reversal: the first Kyverno conference talk, at KCD Munich 2023, was titled "Securing Your Kubernetes Workloads with Kyverno", and three years of production work later the talks are about governance, CEL and platform self-service [s1c14]. A separate post of theirs on the Platform Engineering blog argued that Kyverno has outgrown "policy engine" as a description entirely [s1c15]. The post also concedes the security work is real: it blocks insecure configs, enforces PSS, verifies image signatures, and genuinely helps with compliance [s1c16].

What to watch: this post is billed as the opening argument of a longer series on policy-driven platform engineering [s1c17], so the concrete platform patterns are the ones to judge it on. For anyone running Kyverno internally, the cheap diagnostic is a count of policies by type. If everything in the cluster is a validation rule, the tool is doing the job its budget line asked for and not the one the post says pays.