📚 课程目录第1章 Kyverno概述

回滚护栏即代码：Kyverno与自动化流水线集成调试 - 第1节

1.1 Kyverno 是什么

Kyverno 是专为 Kubernetes 设计的云原生策略引擎，由 Nirmata 公司开源，后捐献给 CNCF 成为孵化项目。它的核心思想是“策略即代码”（Policy as Code），允许用户通过声明式 YAML 资源定义策略，无需编写复杂的 DSL 或学习新语言。

Kyverno 以 Kubernetes 动态准入控制器（Dynamic Admission Controller）的形式运行，拦截 API Server 的请求（CREATE、UPDATE、DELETE），根据预定义的策略规则进行校验、变更或生成资源。它原生支持 Kubernetes 资源模型，能够直接操作 Pod、Deployment、Service 等内置资源，也支持 CRD 自定义资源。

  一句话定义：Kyverno = Kubernetes 原生的策略引擎，用 YAML 写策略，无需新语言，无需 Sidecar，无需重新编译 API Server。

1.1.1 工作流程

策略定义：用户创建 ClusterPolicy 或 Policy 资源，描述匹配规则和动作。
Webhook 注册：Kyverno 自动注册 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration。
请求拦截：API Server 将匹配的请求发送给 Kyverno 的 Webhook 端点。
策略执行：Kyverno 按优先级依次执行策略，支持 mutate、validate、generate 三种动作。
响应返回：Kyverno 返回准入响应（允许/拒绝/补丁），API Server 据此处理请求。

1.2 Kyverno vs OPA/Gatekeeper 对比

OPA（Open Policy Agent）和 Gatekeeper 是 Kyverno 最常被拿来对比的竞品。三者都解决 Kubernetes 策略执行问题，但设计哲学和实现路径有本质差异。

对比维度	Kyverno	OPA / Gatekeeper
策略语言	YAML（声明式，无新语言）	Rego（声明式 + 逻辑编程）
学习曲线	低（熟悉 K8s YAML 即可）	中高（需学习 Rego 语法）
策略动作	validate / mutate / generate	validate（mutate 需额外配置）
资源生成	原生支持（generate 动作）	不支持
背景扫描	内置（报告现有资源合规）	需额外工具（如 kube-mgmt）
策略测试	内置 CLI（kyverno test）	需 opa test + 模拟数据
社区生态	策略库（~200+ 预置策略）	Rego 库 + Gatekeeper 约束模板
性能开销	低（原生 Go 实现）	中（Rego 编译 + 查询）
调试复杂度	低（YAML 错误易定位）	中高（Rego 调试需 trace）

选型建议：如果团队以 Kubernetes 原生操作为主，希望快速上手、减少学习成本，优先选择 Kyverno。如果已有 OPA 投资、需要跨平台策略统一（K8s + 微服务 + API 网关），或策略逻辑极其复杂（如图遍历、递归查询），OPA/Gatekeeper 更合适。

1.3 核心优势

1.3.1 零学习成本策略编写

Kyverno 策略本身就是 Kubernetes 资源（ClusterPolicy / Policy），使用 YAML 定义 match 和 exclude 规则，配合 validate、mutate、generate 动作。熟悉 K8s 的工程师无需学习新语言即可编写策略。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-required-labels
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "标签 'app.kubernetes.io/name' 是必需的"
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?*"

1.3.2 三种原生策略动作

validate：校验资源是否符合规范，支持 deny、pattern、anyPattern、podSecurity 等子规则。
mutate：在资源持久化前自动修改字段，支持 patchStrategicMerge、patchesJson6902、overlay 等模式。
generate：根据源资源自动生成新资源（如为每个 Namespace 生成 NetworkPolicy、ResourceQuota）。

1.3.3 原生 CI/CD 集成能力

Kyverno 提供 CLI 工具，可在流水线中离线执行策略检查，无需连接集群。支持 kyverno apply、kyverno test、kyverno jp 等命令，与 GitOps 和 CI/CD 流水线天然契合。

1.3.4 策略即代码的完整生命周期

编写：YAML 文件，可纳入 Git 版本管理。
测试：内置 kyverno test 命令，支持本地测试用例。
部署：kubectl apply 或 Helm Chart 分发。
审计：背景扫描 + 合规报告。
调试：详细的策略执行日志 + 策略报告资源。

1.4 适用场景

1.4.1 安全基线加固

禁止特权容器、hostNetwork、hostPID 等高危配置。
强制只读根文件系统、非 root 用户运行。
限制容器 capabilities、seccomp、AppArmor 配置。
自动注入 Sidecar（如 Istio、日志采集代理）。

1.4.2 合规治理

PCI-DSS：强制加密存储、网络隔离、审计日志。
SOC2：资源标签标准化、访问控制策略。
内部合规：镜像来源校验、资源配额限制。

1.4.3 CI/CD 流水线门禁

在 PR 合并前执行策略检查，阻止不合规资源进入集群。
GitOps 工作流中自动验证 ArgoCD/Flux 同步的资源。
生成合规报告，作为流水线质量门禁的一部分。

1.4.4 资源标准化与自动修复

自动为所有 Deployment 添加 app.kubernetes.io/name 标签。
为每个 Namespace 自动生成 ResourceQuota 和 NetworkPolicy。
自动注入 Pod 安全上下文、资源 requests/limits。

注意：Kyverno 的 mutate 动作虽然强大，但可能引发资源漂移（drift）。建议在 mutate 策略中设置 mutateExistingOnPolicyUpdate: true 时谨慎评估影响范围，避免生产环境意外变更。

1.5 本章小结

Kyverno 作为 Kubernetes 原生的策略引擎，以“零学习成本、声明式 YAML、三种原生动作、完整 CI/CD 集成”为核心竞争力，在安全加固、合规治理、资源标准化、流水线门禁等场景中具有显著优势。与 OPA/Gatekeeper 相比，Kyverno 更适合以 Kubernetes 为中心的团队，尤其是需要快速落地策略即代码、降低运维复杂度的场景。