Kyverno是平台原语，而非安全工具
内容提要
Kyverno不仅是安全工具，更是平台原语。它通过验证、变更、生成和镜像验证四个功能，实现命名空间配置、边车注入、镜像重写等平台自动化。政策即代码，将组织意图转化为基础设施，提升开发者体验和运维效率。
延伸解读
安全框架的局限
文章指出，将Kyverno归类为安全工具会限制其使用范围。安全框架下的核心动词是“拒绝”，导致大多数组织只部署验证策略，而忽略了变更、生成和镜像验证等更具建设性的功能。这种思维定式使得Kyverno仅被用于阻止不安全配置，而未能发挥其作为平台构建模块的全部潜力。
平台原语的四个特征
作者定义平台原语需具备四个属性：抽象复杂性、提供保证、可组合、自助服务。Kyverno策略符合这些特征，例如命名空间装修、边车注入、镜像重写等用例，开发者无需了解底层机制，平台要求自动满足。这使其与Pod、Service等原生原语并列，成为平台工程的基础组件。
策略即平台意图的API
文章提出，政策即代码将组织信念从文档转化为基础设施。通过GitOps交付策略，平台规则不再依赖个人记忆或人工审查，而是内置于系统。这改变了策略的交付方式，使渐进式推出、异常管理成为常态，并扩展了GitOps的职责范围，但也带来了策略变更与资源所有权之间的协调挑战。
Q&A
Kyverno 为什么被认为是平台原语而不是安全工具？
因为 Kyverno 的核心功能（验证、变更、生成、镜像验证）中，只有验证符合安全工具的“门禁”模式，其余三个都是建设性的，用于添加、修改或构建资源。平台团队利用它实现命名空间配置、边车注入、镜像重写等自动化，这些都不是安全功能，而是平台自动化和开发者体验的组成部分。
Kyverno 的四个主要功能是什么？
Kyverno 的四个主要功能是：验证（validate）、变更（mutate）、生成（generate）和镜像验证（verify images）。验证用于检查资源是否符合策略，变更用于修改资源，生成用于创建新资源，镜像验证用于确认镜像签名和来源。
平台团队使用 Kyverno 的典型场景有哪些？
典型场景包括：命名空间配置（自动生成 NetworkPolicy、ResourceQuota 等）、边车注入（自动添加代理或监控容器）、镜像引用重写（将镜像地址改为内部镜像仓库）、默认资源请求注入（为 Pod 设置默认 CPU/内存请求）、所有权标签（自动添加团队、成本中心等标签）。
Kyverno 如何实现策略即代码？
Kyverno 允许将组织规则写成代码，存储在 Git 仓库中，通过 GitOps 工具（如 Argo CD 或 Flux）部署。这些策略在 Kubernetes 资源创建或更新时自动执行，将文档化的规则转化为基础设施的一部分，实现自动化和一致性。
Kyverno 的四个功能如何对应平台能力？
验证对应护栏（guardrails），变更对应铺好的路（paved roads），生成对应脚手架（scaffolding），镜像验证对应信任（trust）。这些能力帮助平台团队构建自动化和自服务的基础设施。
将 Kyverno 视为安全工具会带来什么问题？
将 Kyverno 视为安全工具会导致过度关注验证策略，而忽略变更、生成等建设性功能，从而只使用了 Kyverno 的一小部分能力。这限制了平台自动化和开发者体验的提升。
Kyverno 如何提升开发者体验？
通过自动注入边车、重写镜像引用、生成默认资源请求等，开发者无需手动配置这些细节，只需编写简单的 Deployment 清单，平台自动满足要求，减少了认知负担和错误。
