3. Kyverno 架构与核心概念：Policy、Rule、Match/Exclude、Mutate/Validate/Generate

Kyverno 作为 Kubernetes 原生的策略引擎，其架构设计围绕 策略（Policy） 这一核心抽象展开。理解 Policy、Rule、Match/Exclude、Mutate/Validate/Generate 这五大概念，是掌握 Kyverno 准入控制的基础。本章将逐一拆解这些概念，并展示它们如何协同工作，实现对 CRD 及所有 Kubernetes 资源的合规保护。

3.1 核心架构总览

Kyverno 以 Webhook 模式运行，拦截 Kubernetes API Server 的请求，并根据用户定义的策略进行校验或修改。其核心组件与数据流如下图所示：

3.2 Policy（策略）

Policy 是 Kyverno 中最高级别的抽象，代表一组规则的集合。Kyverno 提供两种策略类型：

一个典型的 Policy 定义结构如下：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-crd-label
spec:
  validationFailureAction: Enforce   # 或 Audit
  rules:
    - name: check-crd-label
      match:
        resources:
          kinds:
            - CustomResourceDefinition
      validate:
        message: "CRD 必须包含 'app.kubernetes.io/managed-by' 标签"
        pattern:
          metadata:
            labels:
              app.kubernetes.io/managed-by: "?*"

3.3 Rule（规则）

每个 Policy 可以包含一个或多个 Rule。Rule 是策略执行的最小单元，由三个核心部分组成：

• Match/Exclude：定义规则适用的资源范围
• Mutate/Validate/Generate：定义规则执行的具体动作
• Context（可选）：提供外部数据源，如 ConfigMap、API 调用结果等

Rule 的执行顺序遵循 Kyverno 内部优先级：Mutate → Validate → Generate。这意味着修改操作先于校验操作执行，生成操作最后执行。

3.4 Match 与 Exclude（匹配与排除）

Match 和 Exclude 是 Rule 的 选择器，决定规则作用于哪些资源。它们支持多种匹配维度：

Match 和 Exclude 的关系遵循 先匹配后排除 的逻辑：

1. Kyverno 首先检查资源是否满足 Match 条件
2. 如果满足，再检查是否命中 Exclude 条件
3. 只有同时满足 Match 且不命中 Exclude 的资源才会被规则处理

3.5 Mutate、Validate、Generate（三大动作）

这是 Kyverno 规则的 执行体，定义了规则对资源的具体操作。三者功能对比如下：

3.5.1 Mutate（修改）

Mutate 支持两种修改模式：

• patchStrategicMerge：使用 Kubernetes 策略合并补丁，适合覆盖或添加字段
• patchesJson6902：使用 JSON Patch 标准，支持更精细的增删改操作

# 示例：自动为 CRD 添加合规标签
mutate:
  patchStrategicMerge:
    metadata:
      labels:
        (app.kubernetes.io/managed-by): kyverno
        (security.kyverno.io/scan): required

3.5.2 Validate（校验）

Validate 提供多种校验方式：

# 示例：校验 CRD 必须包含描述信息
validate:
  message: "CRD 必须包含 'description' 字段"
  pattern:
    spec:
      names:
        description: "?*"

3.5.3 Generate（生成）

Generate 允许在特定资源创建时，自动生成关联资源。它支持两种数据源：

• data：直接内联定义要生成的资源内容
• clone：从已有资源克隆生成

# 示例：创建 CRD 时自动生成对应的 RBAC 规则
generate:
  kind: ClusterRole
  name: "crd-{{ request.object.metadata.name }}-viewer"
  synchronize: true
  data:
    rules:
      - apiGroups: ["{{ request.object.spec.group }}"]
        resources: ["{{ request.object.spec.names.plural }}"]
        verbs: ["get", "list", "watch"]

3.6 概念关系总结

以下 SVG 图展示了 Policy、Rule、Match/Exclude、Mutate/Validate/Generate 之间的层级与协作关系：

3.7 策略执行流程

当一个资源请求到达 Kyverno Webhook 时，完整的处理流程如下：

1. 请求拦截：API Server 将 AdmissionReview 请求发送到 Kyverno Webhook
2. 策略匹配：Kyverno 遍历所有 ClusterPolicy 和 Policy，检查资源的 Match/Exclude 条件
3. 规则排序：按 Mutate → Validate → Generate 顺序执行匹配到的规则
4. Mutate 执行：对资源进行修改，修改后的资源进入下一阶段
5. Validate 执行：校验修改后的资源是否合规，不合规则拒绝或记录
6. Generate 执行：在资源创建成功后，异步生成关联资源
7. 响应返回：将 AdmissionResponse 返回给 API Server