1. Kyverno 概述
1.1 项目背景与起源
Kyverno 是由 Nirmata 公司于 2020 年开源、后捐献给 CNCF 的 Kubernetes 原生策略引擎。其名称源自希腊语“κυβερνάω”（kybernáo），意为“掌舵、治理”——恰好对应它在集群中扮演的“策略守门人”角色。
在 Kyverno 出现之前，Kubernetes 生态中主流的策略工具是 OPA/Gatekeeper，它使用 Rego 声明式语言编写策略，学习曲线陡峭，且需要额外部署 Webhook 和模板框架。Kyverno 的设计哲学截然不同：
- Kubernetes 原生：策略用 Kubernetes 资源（
ClusterPolicy/Policy）定义，无需学习新语言。 - 无模板引擎：直接使用 YAML 中的
match/exclude/validate/mutate/generate字段描述策略逻辑。 - 动态准入：自动注册 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration，无需手动管理。
关键里程碑：2022 年 Kyverno 进入 CNCF Incubating 阶段，2023 年成为 CNCF Graduated 项目，社区贡献者超过 400 人，月均下载量突破 2000 万次。
1.2 核心功能矩阵
Kyverno 提供三大类策略操作，覆盖资源从创建到运行的完整生命周期：
| 功能类别 | 操作类型 | 典型场景 | 执行时机 |
|---|---|---|---|
| Validate | 验证（拒绝/告警） | 强制 Pod 安全上下文、禁止特权容器、检查镜像仓库来源 | Admission Review 阶段 |
| Mutate | 修改（覆盖/补丁） | 自动注入 Sidecar、添加标签/注解、设置默认资源限制 | Admission Review 阶段（先于 Validate） |
| Generate | 生成（创建附属资源） | 为每个 Namespace 自动创建 NetworkPolicy、RBAC 绑定、配额 | 资源创建后（Background 模式） |
| VerifyImages | 镜像签名验证 | 使用 Cosign 验证容器镜像签名与 attestation | Admission Review 阶段（扩展 Validate） |
| Cleanup | 清理（定时删除） | 删除过期 Job、未使用的 PVC、残留 ConfigMap | 定时任务（CronJob 模式） |
性能提示：Mutate 操作在 Validate 之前执行，且 Mutate 的结果会作为 Validate 的输入。因此，如果策略同时包含 mutate 和 validate，应优先优化 mutate 规则的匹配效率，避免不必要的补丁计算。
1.3 在云原生安全中的定位
Kyverno 在云原生安全体系中处于 准入控制层，是“安全左移”的关键落地工具。它与 Kubernetes 安全架构的关系可以用下图概括：
从安全分层视角看，Kyverno 填补了以下关键空白：
- 配置安全基线：强制 PodSecurityStandards（PSS）、禁止 hostNetwork / hostPID / privileged 等危险配置。
- 供应链安全：结合 Cosign 验证镜像签名，确保只有经过审批的镜像才能运行。
- 合规自动化：将 CIS Benchmark、NIST、SOC2 等合规要求转化为可执行的策略规则。
- 运维治理：自动注入 Sidecar、添加标签、生成 NetworkPolicy，减少人工操作失误。
常见误区：Kyverno 不是运行时安全工具（如 Falco、Tracee），它不监控运行中的容器行为；也不是网络策略引擎（如 Calico、CiliumNetworkPolicy）。它的职责范围严格限定在 资源创建/更新时的准入控制 以及 后台资源生成与清理。
1.4 策略执行模型
Kyverno 的策略执行遵循“匹配 → 操作 → 响应”的三段式模型：
策略的 failureAction 字段决定了匹配失败时的行为：
| failureAction | 行为 | 适用场景 |
|---|---|---|
Enforce |
拒绝违反策略的请求，返回 AdmissionResponse 中的错误 | 生产环境强制安全基线 |
Audit |
允许请求通过，但在策略报告中记录违反事件 | 灰度验证、策略效果评估、合规审计 |
最佳实践：新策略上线时先使用
Audit 模式运行 24-48 小时，通过 kubectl get policyreport 观察违反情况，确认无预期外影响后再切换为 Enforce 模式。
1.5 与 OPA/Gatekeeper 的对比
作为 Kubernetes 策略引擎领域的两大主流方案，Kyverno 与 OPA/Gatekeeper 在设计理念和运维体验上存在显著差异：
| 维度 | Kyverno | OPA / Gatekeeper |
|---|---|---|
| 策略语言 | YAML（Kubernetes 原生资源） | Rego（声明式查询语言） |
| 学习曲线 | 低（熟悉 K8s YAML 即可上手） | 中高（需学习 Rego 语法与逻辑） |
| 安装复杂度 | 低（单 Helm Chart / 单 YAML） | 中（需部署 OPA + Gatekeeper + ConstraintTemplate） |
| 策略模板 | 无模板层，直接定义规则 | 需定义 ConstraintTemplate + Constraint |
| 内置功能 | Mutate、Generate、VerifyImages、Cleanup | 仅 Validate（需额外开发 Mutation） |
| 性能基准 | 单进程内联执行，延迟较低 | 外部 OPA 服务调用，网络开销略高 |
| 社区生态 | CNCF Graduated，400+ 贡献者 | CNCF Graduated，更广泛的通用策略生态 |
选型建议：如果团队以 Kubernetes 工程师为主、希望快速落地安全基线且避免学习新语言，Kyverno 是更优选择；如果已有 OPA 投资、需要跨平台（K8s + 微服务 + 基础设施）统一策略引擎，则 OPA/Gatekeeper 更合适。