4. Kyverno 策略语言入门：策略结构、规则定义与动作类型

Kyverno 策略语言的核心设计哲学是“Kubernetes 原生”——策略本身就是 Kubernetes 资源（CRD），使用 YAML 声明式定义，无需学习额外的 DSL（领域特定语言）。本章将系统拆解策略的顶层结构、规则（rule）的构成要素、选择器（match/exclude）的匹配逻辑，以及三种核心动作类型（validate/mutate/generate）的适用场景。

4.1 策略顶层结构：Policy 与 ClusterPolicy

Kyverno 提供两种策略作用域，区别在于生效范围与资源类型：

4.2 规则（rule）定义：策略的最小执行单元

每个策略可以包含多个规则，规则之间是“OR”逻辑——只要有一条规则匹配并执行动作，策略即生效。规则的 YAML 骨架如下：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-pod-security
spec:
  rules:
    - name: require-readonly-rootfs
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - resources:
              namespaces:
                - kube-system
      validate:
        message: "根文件系统必须设置为只读"
        pattern:
          spec:
            containers:
              - securityContext:
                  readOnlyRootFilesystem: true

规则的核心字段包括：

• name（必填）：规则标识，在策略内唯一，用于审计日志与告警。
• match（必填）：定义哪些资源触发该规则，支持 any 或 all 条件组。
• exclude（可选）：从匹配结果中排除特定资源，优先级高于 match。
• 动作类型（三选一）：validate、mutate、generate，决定规则对资源执行的操作。
• context（可选）：从外部数据源（如 ConfigMap、API 调用）注入变量，用于动态策略。

4.3 match/exclude 选择器：精准控制策略作用域

选择器是策略的“瞄准镜”，通过资源属性组合实现精细匹配。Kyverno 支持两种逻辑运算符：

• any：满足任意一个条件即匹配（OR 逻辑）。
• all：满足所有条件才匹配（AND 逻辑）。

常用的匹配维度包括：

4.4 三种动作类型：validate / mutate / generate

动作类型是策略的“执行器”，决定了规则对匹配资源的具体操作。下表对比三种动作的核心差异：

4.4.1 validate：准入校验与拒绝

validate 是使用最频繁的动作类型，支持两种校验模式：

• pattern：声明期望的资源字段值，Kyverno 检查实际值是否匹配。支持通配符 * 和条件操作符（如 >、<）。
• deny：基于 CEL（Common Expression Language）或原始条件表达式，当条件为 true 时拒绝请求。适用于复杂逻辑校验。

# pattern 模式示例：强制容器镜像必须来自内部仓库
validate:
  message: "镜像必须来自 registry.internal.io"
  pattern:
    spec:
      containers:
        - image: "registry.internal.io/*"

4.4.2 mutate：自动修改与注入

mutate 在资源被创建或更新时自动修改其字段，用户无需手动操作。支持两种策略：

• patchesJson6902：使用 JSON Patch 标准（RFC 6902）进行精确修改。
• patchStrategicMerge：使用 Kubernetes 战略合并补丁，适合覆盖或追加字段。

# 自动为所有 Pod 添加标签 "team: platform"
mutate:
  patchStrategicMerge:
    metadata:
      labels:
        team: platform

4.4.3 generate：资源自动创建

generate 在触发资源（如 Namespace）创建后，自动生成关联资源。常用于平台初始化场景：

• 为每个新 Namespace 生成默认的 NetworkPolicy（拒绝所有入站流量）。
• 为每个 ServiceAccount 生成对应的 Secret（用于镜像拉取）。
• 为每个 Namespace 生成 ResourceQuota 和 LimitRange。

# 自动为每个 Namespace 生成默认网络策略
generate:
  kind: NetworkPolicy
  name: default-deny-ingress
  namespace: "{{request.object.metadata.name}}"
  synchronize: true
  data:
    spec:
      podSelector: {}
      policyTypes:
        - Ingress

4.5 策略执行流程与规则优先级

当 Kubernetes API Server 收到资源请求时，Kyverno 作为动态准入 Webhook 介入，执行流程如下：

1. 匹配阶段：遍历所有 ClusterPolicy 和 Policy，检查资源的 kind、namespace、labels 等是否匹配规则的 match 条件。
2. 排除阶段：对匹配的资源，检查 exclude 条件，排除命中项。
3. 动作执行：按 mutate → validate → generate 的顺序执行。mutate 先修改资源，validate 再校验修改后的结果，generate 在资源持久化后异步执行。
4. 结果聚合：所有规则执行完毕后，Kyverno 向 API Server 返回允许/拒绝/补丁响应。

4.6 策略语言核心概念总结

Kyverno 策略语言的本质是“用 Kubernetes 资源描述安全规则”。掌握以下三个关键点即可快速上手：

• 结构分层：Policy/ClusterPolicy → rules[] → match/exclude → 动作类型，每一层都有明确的职责边界。
• 选择器灵活性：通过 any/all 组合资源类型、标签、命名空间等维度，实现从粗粒度到细粒度的策略控制。
• 动作类型分工：validate 做“安检”，mutate 做“自动修正”，generate 做“资源预置”，三者配合可覆盖绝大多数安全权限场景。