📚 课程目录第4章 Kyverno策略引擎基础

4. Kyverno 策略引擎基础：Policy 与 Rule 结构、match/exclude 规则、背景上下文（context）与变量

Kyverno 是专为 Kubernetes 设计的策略引擎，其核心抽象是 Policy（策略）与 Rule（规则）。理解 Policy/Rule 的声明式结构、匹配/排除逻辑、以及上下文变量机制，是编写生产级安全门禁策略的前提。本章将拆解这些基础概念，并展示它们如何协同工作。

4.1 Policy 与 Rule 的层级结构

一个 Kyverno Policy 资源（ClusterPolicy 或 Policy）包含一个或多个 Rule。每个 Rule 定义了一个独立的“条件-动作”单元：当 match 条件满足且 exclude 条件不满足时，执行 validate、mutate、generate 或 verifyImages 动作。

层级	字段	说明
Policy	`spec.rules[]`	规则列表，每个规则独立评估
Rule	`match`	选择目标资源（必须匹配）
Rule	`exclude`	排除特定资源（可选）
Rule	`context`	声明外部数据源（API 调用、ConfigMap、变量）
Rule	`validate`/`mutate`/`generate`/`verifyImages`	动作定义

  关键区别： ClusterPolicy 作用于集群范围，Policy 作用于特定命名空间。在镜像安全水位场景中，通常使用 ClusterPolicy 以覆盖所有工作负载。

4.2 match 与 exclude 规则：精准选择目标

match 和 exclude 使用相同的资源描述结构，支持按 资源类型、标签、注解、命名空间选择器 等维度进行筛选。规则之间是 AND 逻辑：所有条件必须同时满足。

4.2.1 match 示例：选择高风险命名空间中的 Pod

match:
  any:
  - resources:
      kinds:
      - Pod
      namespaces:
      - "production"
      - "staging"
      selector:
        matchLabels:
          security-tier: "critical"

4.2.2 exclude 示例：排除系统组件

exclude:
  any:
  - resources:
      namespaces:
      - kube-system
      - kyverno
  - resources:
      kinds:
      - DaemonSet
      name: "node-exporter*"

最佳实践： 在镜像水位策略中，始终排除 kube-system、kyverno 等系统命名空间，避免误拦截基础设施组件。

4.3 背景上下文（context）与变量

context 是 Kyverno 策略的“数据注入层”。它允许规则在执行时动态获取集群内外的信息，并将结果绑定为变量，供 validate/mutate 表达式引用。常见的 context 类型包括：

ConfigMap：从指定命名空间的 ConfigMap 中读取键值对。
APICall：调用 Kubernetes API 或其他 HTTP 服务，获取 JSON 响应。
ImageRegistry：查询容器镜像仓库的元数据（如摘要、标签列表）。
Variable：引用其他规则或预定义变量。

4.3.1 context 声明示例：从 ConfigMap 读取安全水位阈值

context:
- name: securityThreshold
  configMap:
    name: image-security-config
    namespace: kyverno-policies

4.3.2 变量引用语法

在 validate/mutate 表达式中，使用 {{ context.变量名.字段路径 }} 引用 context 数据。Kyverno 还提供内置变量：

变量	说明
`{{ request.object }}`	被评估资源的完整对象
`{{ request.operation }}`	操作类型：CREATE、UPDATE、DELETE
`{{ images.containers.*.name }}`	工作负载中所有容器名称列表
`{{ images.containers.*.reference }}`	容器镜像完整引用（含标签/摘要）

注意： 变量引用区分大小写，且 context 数据必须在规则执行前完成加载。如果 context 调用失败（如 ConfigMap 不存在），规则将默认拒绝请求（fail-on-error 行为）。

4.4 策略执行流程与上下文数据流

下图展示了 Kyverno 在处理一个 AdmissionReview 请求时，Policy、Rule、match/exclude、context 与变量之间的完整数据流：

4.5 综合示例：基于安全水位的镜像验证策略

以下是一个完整的 ClusterPolicy，它结合了 match/exclude、context 和变量，实现“仅允许安全水位达标的镜像通过变更”：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-security-watermark
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-watermark
    match:
      any:
      - resources:
          kinds:
          - Pod
          namespaces:
          - "production"
          - "staging"
    exclude:
      any:
      - resources:
          namespaces:
          - kube-system
          - kyverno
    context:
    - name: watermarkConfig
      configMap:
        name: image-watermark
        namespace: kyverno-policies
    - name: imageScanResult
      apiCall:
        urlPath: "/apis/scanning.example.com/v1/imagescans"
        jmesPath: "items[?image == '{{ request.object.spec.containers[0].image }}'].status.watermark | [0]"
    validate:
      message: "镜像 {{ request.object.spec.containers[0].image }} 的安全水位 {{ imageScanResult }} 低于阈值 {{ watermarkConfig.data.minWatermark }}"
      deny:
        conditions:
          any:
          - key: "{{ imageScanResult }}"
            operator: LessThan
            value: "{{ watermarkConfig.data.minWatermark }}"

  策略解读： 该策略通过 context 从 ConfigMap 读取最低水位阈值，同时调用外部 API 获取镜像的扫描结果。如果扫描水位低于阈值，则拒绝 Pod 创建/更新请求。exclude 规则确保系统组件不受影响。

4.6 本章小结

Policy/Rule 结构：ClusterPolicy 包含多个 Rule，每个 Rule 独立执行 match→exclude→context→action 流程。
match/exclude：支持按资源类型、标签、命名空间等维度精准筛选，规则间为 AND 逻辑。
context 与变量：context 是动态数据源，变量通过 {{ }} 语法引用，是策略灵活性的核心。
安全水位场景：通过 context 加载外部扫描结果和配置阈值，实现基于数据驱动的变更门禁。