4. 策略引擎核心概念：Policy、Rule、Match、Exclude、Mutate、Validate、Generate

Kyverno 策略引擎围绕一组精确定义的核心概念构建。理解 Policy、Rule、Match、Exclude、Mutate、Validate 和 Generate 之间的关系，是编写高效、可维护策略的基础。本节将逐一拆解这些概念，并展示它们如何在引擎中协同工作。

4.1 策略（Policy）与规则（Rule）

Policy 是 Kyverno 中的顶级资源对象，它包含一个或多个 Rule。Policy 定义了策略的生效范围（集群级别或命名空间级别），而 Rule 则定义了具体的匹配条件和执行动作。

概念 作用域 核心职责 示例
Policy 集群 / 命名空间 策略的容器，定义生效范围、后台扫描模式、失败行为 ClusterPolicy 或 Policy
Rule Policy 内部 定义匹配条件（Match/Exclude）和执行动作（Mutate/Validate/Generate） 一条规则：匹配所有 Pod，验证是否包含 runAsNonRoot: true
关键区别： Policy 是“策略文件”，Rule 是“策略逻辑单元”。一个 Policy 可以包含多条 Rule，引擎会按顺序评估每条 Rule。

4.2 匹配（Match）与排除（Exclude）

Match 和 Exclude 是 Rule 的“过滤器”。它们决定了当前 Rule 应该应用于哪些 Kubernetes 资源。两者都支持基于资源类型、标签选择器、命名空间、名称、用户信息等条件进行筛选。

  • Match：定义规则应该应用的资源集合。只有匹配的资源才会进入后续的 Mutate/Validate/Generate 处理流程。
  • Exclude：定义规则不应该应用的资源集合。Exclude 的优先级高于 Match，即如果一个资源同时匹配了 Match 和 Exclude，该资源会被排除。
最佳实践： 使用 Exclude 来豁免特定的命名空间（如 kube-system）或特定的标签（如 app: istio-init），避免策略误伤基础设施组件。

4.3 三大动作：Mutate、Validate、Generate

这是 Kyverno 策略引擎的核心执行能力。每条 Rule 必须且只能选择其中一个动作。

动作 触发时机 行为描述 典型场景
Mutate Admission 请求时 在资源持久化到 etcd 之前，修改资源的配置。可以覆盖、补丁或删除字段。 自动注入 Sidecar 容器、添加安全上下文、设置资源限制
Validate Admission 请求时 / 后台扫描 检查资源是否符合预期规范。如果不符合，可以拒绝请求（enforce）或生成告警（audit）。 强制要求所有镜像来自私有仓库、禁止特权容器、检查标签合规性
Generate Admission 请求时 / 后台扫描 根据源资源或模板，创建新的 Kubernetes 资源。生成的资源与源资源保持同步。 为每个 Namespace 自动创建 NetworkPolicy、为每个 Deployment 生成对应的 ServiceAccount
注意： Generate 动作在创建资源时，会触发新的 Admission 请求，这可能导致递归生成。Kyverno 通过 generate.kyverno.io/generated-by 标签来防止无限循环。

4.4 核心概念关系图

下图展示了 Policy、Rule、Match/Exclude 以及三大动作之间的完整数据流关系：

Kyverno 策略引擎核心概念关系图 Policy / ClusterPolicy Rule Match Exclude Mutate Validate Generate 说明： 1. 一个 Policy 包含一个或多个 Rule。 2. 每个 Rule 必须定义 Match（必须）和 Exclude（可选），然后选择 Mutate / Validate / Generate 之一。

4.5 动作执行顺序与引擎流程

当一个 Admission 请求到达 Kyverno 时，引擎会按照以下顺序处理所有匹配的 Rule：

  1. Match 检查： 遍历所有 Policy 中的所有 Rule，检查请求资源是否匹配 Rule 的 Match 条件。
  2. Exclude 检查： 对匹配的 Rule，进一步检查 Exclude 条件。如果命中 Exclude，则跳过该 Rule。
  3. Mutate 执行： 所有匹配的 Mutate Rule 按顺序执行，对资源进行修改。修改后的资源会传递给后续的 Validate 和 Generate 步骤。
  4. Validate 执行： 所有匹配的 Validate Rule 按顺序执行。如果任何一条 Validate Rule 失败（enforce 模式），整个请求将被拒绝。
  5. Generate 执行： 所有匹配的 Generate Rule 按顺序执行，创建或更新关联资源。
重要顺序： Mutate 总是在 Validate 之前执行。这意味着 Validate 规则检查的是经过 Mutate 修改后的资源状态，而不是用户原始提交的配置。这一特性常用于“先注入安全配置，再验证合规性”的场景。

4.6 完整策略示例：安全基线组合

以下是一个结合了 Mutate 和 Validate 的完整策略示例，展示了核心概念如何协同工作：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: pod-security-baseline
spec:
  validationFailureAction: Enforce
  rules:
    # Rule 1: Mutate - 自动添加只读根文件系统
    - name: auto-readonly-rootfs
      match:
        resources:
          kinds:
            - Pod
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                securityContext:
                  readOnlyRootFilesystem: true

    # Rule 2: Validate - 禁止特权容器
    - name: disallow-privileged
      match:
        resources:
          kinds:
            - Pod
      exclude:
        resources:
          namespaces:
            - kube-system
      validate:
        message: "特权容器是不允许的。"
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: false
策略解读： 该策略包含两条 Rule。第一条 Rule 使用 Mutate 自动为所有 Pod 容器添加 readOnlyRootFilesystem: true。第二条 Rule 使用 Validate 检查所有 Pod（排除 kube-system 命名空间）是否包含 privileged: false。由于 Mutate 先执行，用户提交的 Pod 即使没有设置 readOnlyRootFilesystem，也会被自动补全，然后 Validate 规则再检查特权设置。
← 上一章 📖 返回目录 下一章 →