Koray Oksay 是 CNCF 大使。他认为，企业通常将 Kyverno 置于安全团队的职责范围内，用它来验证 Kubernetes 配置、阻止以 root 权限运行的容器，或强制执行容器安全标准，随后却忽略了其很大一部分能力。按照 Oksay 的观点，这种思维分类将 Kyverno 限定为阻止错误配置的“门禁”，而实际上，平台团队可以将其作为构建平台服务和运行规则的基础构件。
这一观点源于作者的经历：他曾在 2023 年 KCD Munich 大会上发表题为“使用 Kyverno 保护 Kubernetes 工作负载”的演讲。经过三年生产环境实践后，他表示自己的关注点已转向治理、CEL 和平台自助服务，而将 Kyverno 称为“策略引擎”已不足以涵盖其范围。
为什么安全分类还不够？
Oksay 并不否认 Kyverno 的安全功能。该平台能够阻止不安全配置、强制执行 Pod Security Standards，并验证容器镜像签名。但仅将其与安全联系起来，会固化一种把策略视为门槛的模式，其主要目标是拒绝请求，成功与否则以阻止的部署数量来衡量。
相比之下，作者将 Kyverno 的主要功能归纳为四类：验证、修改、生成和镜像验证。验证功能直接属于门禁模式；修改功能会在资源进入集群前改变资源；生成功能会响应特定事件创建新资源；而镜像验证关注的是建立对镜像的信任，而不仅仅是阻止威胁。因此，他认为四项功能中有三项具有建设性，但许多企业只使用验证策略。
什么是平台核心组件？
Oksay 使用“核心组件”一词时，采用的是接近其在编程语言中的含义：一个小型且易于理解的构件，可以组合起来构建更大的系统。要让这一构件在平台中发挥实际作用，它应当向开发者隐藏复杂性，提供自动化保障，与其他构件集成，并通过自助服务提供，而不是依赖人工请求或支持队列。
在这一意义上，Kyverno 策略类似于 Pods、Services、ConfigMaps 和 Crossplane 组合等组件。它们将企业采用的规则转化为平台内部的自动行为。
平台团队如何使用它？
- 准备命名空间：创建命名空间时，Kyverno 可以生成默认的 NetworkPolicy、ResourceQuota、LimitRange 和 RoleBindings，使命名空间无需开发者记住一长串手动步骤即可完成准备。
- 注入边车容器：可以在准入阶段向 Pod 规范中添加监控代理、网络代理或秘密同步容器，同时保持 Deployment 文件简洁。
- 重写镜像引用：可以将类似 nginx:1.25 的引用转换为 mirror.internal/nginx:1.25，使拉取操作通过内部镜像，而不必要求每位开发者手动添加前缀。
- 添加默认资源请求：与其阻止未指定 CPU 和内存请求的 Pods，不如注入适当的值，并在需要时进行调整。
- 设置归属标签：当团队、成本中心和环境的值明确时，可以添加相应标签；当不明确会产生影响时，也可以强制要求提供这些标签。
实际会发生什么变化？
这些用法共同体现了一个理念：将组织共识转化为不可见的自动化保障。规则可能是安全性的，例如禁止高权限容器；也可能是运营性的，例如强制设置资源限制；还可能是财务性的，例如将每个资源关联到成本中心标签。与其让这些规则停留在 Wiki、检查清单或某位工程师的知识中，不如将其写成代码策略，保存于 Git 中，并通过 GitOps 工具和 Kyverno 执行。
这一视角建议将策略视为平台表达组织意图的接口。应用这一视角后，Kyverno 的功能会转化为不同层次：验证提供防护栏，修改为开发者铺设“黄金路径”，生成提供模板或初始配置，而镜像验证则建立信任。
团队还会将策略视为具有版本、用户、停用周期和可追踪例外的产品。策略的发布可以先从审计开始，然后进入警告阶段，最后逐步强制执行。作者还指出，当策略修改了 Argo CD 或 Flux 认为归其所有的资源时，可能出现协调挑战，并由此导致同步循环。
Oksay 得出的结论是，仅将 Kyverno 理解为安全指南，会掩盖其接口和能力的很大一部分。在他看来，Kyverno 并不是站在集群入口的守卫，而是连接平台团队的观点与资源及应用实际行为的一层。