📚 课程目录第2章 Kyverno基础回顾

Kyverno 基础回顾：策略引擎核心概念、策略类型与执行模式

在深入审计日志设计之前，必须重新夯实 Kyverno 的策略引擎基础。Kyverno 是一个为 Kubernetes 量身定制的策略引擎，它利用 Kubernetes 原生的 Admission Webhook 机制，以声明式 YAML 定义策略，无需编写复杂的准入控制器代码。本节将系统梳理其核心概念、三种策略类型以及执行模式，为后续回滚护栏的日志埋点奠定理论基础。

3.1 核心概念：策略、规则与匹配

Kyverno 的策略模型围绕三个核心抽象构建：策略（Policy）、规则（Rule）和匹配条件（Match/Exclude）。理解这三者的层级关系是编写任何策略的前提。

概念	层级	说明	示例
ClusterPolicy / Policy	顶层	策略的集合，作用域为集群（ClusterPolicy）或命名空间（Policy）。包含一个或多个规则。	`require-pod-labels`
Rule	中间	策略内的具体执行单元，包含 match、exclude、mutate/validate/generate 以及背景扫描配置。	`check-app-label`
Match / Exclude	底层	定义规则适用的资源范围（资源类型、标签选择器、命名空间、用户信息等）。	`match: resources: kinds: ["Pod"]`

关键区分： ClusterPolicy 作用于整个集群，而 Policy 仅作用于其所在的命名空间。在审计日志设计中，回滚护栏通常定义为 ClusterPolicy，以确保对所有命名空间的资源变更进行统一拦截与记录。

3.2 策略类型：Mutate / Validate / Generate

Kyverno 提供三种核心策略类型，分别对应资源生命周期的不同干预阶段。回滚护栏主要依赖 Validate 和 Mutate 类型，但理解 Generate 有助于构建完整的策略生态。

Mutate（变更策略）：在资源创建或更新时，自动修改资源的字段。常用于注入 Sidecar、添加默认标签、修正安全上下文等。回滚护栏中，Mutate 可用于在资源上强制添加审计标签或注解。
Validate（验证策略）：在资源创建或更新时，检查资源是否符合规范。验证结果可以是 pass（通过）、fail（拒绝）或 warn（警告）。回滚护栏的核心逻辑——拒绝不符合回滚条件的变更——正是通过 Validate 策略的 deny 动作实现。
Generate（生成策略）：在资源创建或更新时，自动生成新的关联资源。例如，创建 Namespace 时自动生成 NetworkPolicy 或 ResourceQuota。回滚护栏中较少直接使用，但可用于生成审计配置或默认的 RBAC 规则。

  回滚护栏策略类型选择：
  Validate + deny：用于阻止违反回滚规则的变更（如删除受保护的 Deployment）。
Mutate：用于在资源上自动注入回滚相关的元数据（如 rollback-protection: enabled 标签）。
Generate：用于在创建资源时自动生成审计日志目标（如创建 ConfigMap 存储审计规则）。

3.3 策略执行模式：Admission 控制与背景扫描

Kyverno 支持两种执行模式，理解它们的差异对于审计日志的触发时机至关重要。

执行模式	触发时机	作用域	审计日志关联
Admission 控制	资源创建、更新、删除的 API 请求到达 kube-apiserver 时	实时拦截	高优先级：记录每一次被拦截或修改的变更请求
背景扫描（Background Scan）	周期性或手动触发，扫描集群中已有资源	事后合规检查	中优先级：记录不符合当前策略的存量资源

回滚护栏的审计日志主要依赖 Admission 控制模式，因为该模式能在变更发生前捕获请求并记录详细的上下文（用户、操作、资源版本等）。背景扫描则用于生成合规报告，辅助审计人员发现已存在的“未受保护”资源。

3.4 策略定义示例：Validate 与 Mutate 的 YAML 结构

以下展示一个典型的 Validate 策略（拒绝删除带有 rollback-protection: enabled 标签的 Deployment）和一个 Mutate 策略（自动注入审计标签）。这些结构是后续审计日志字段提取的基础。

示例 1：Validate 策略（拒绝删除受保护的资源）

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-delete-protected-deployment
spec:
  validationFailureAction: Enforce   # Enforce 表示拒绝请求，Audit 表示仅记录
  rules:
  - name: deny-delete-rollback-protected
    match:
      resources:
        kinds:
        - Deployment
        selector:
          matchLabels:
            rollback-protection: enabled
    exclude:
      subjects:
      - kind: ServiceAccount
        name: cluster-admin-sa
    validate:
      message: "删除受回滚保护的 Deployment 被禁止。请先移除 rollback-protection 标签。"
      deny:
        conditions:
          any:
          - key: "{{ request.operation }}"
            operator: Equals
            value: DELETE

示例 2：Mutate 策略（自动注入审计标签）

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: auto-inject-audit-labels
spec:
  rules:
  - name: inject-rollback-audit-label
    match:
      resources:
        kinds:
        - Deployment
        - StatefulSet
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            +(audit.rollback/version): "{{ request.object.metadata.resourceVersion }}"
            +(audit.rollback/timestamp): "{{ time.now() }}"

注意： 在 Validate 策略中，validationFailureAction: Enforce 会直接拒绝请求，而 Audit 模式仅生成告警但不拦截。回滚护栏应使用 Enforce 模式，同时确保审计日志记录完整的拒绝原因和请求上下文。

3.5 策略执行模式对比总结

下表从审计日志设计的角度，对比 Admission 控制与背景扫描两种模式的关键差异：

维度	Admission 控制	背景扫描
触发时机	实时（API 请求时）	定时（默认每 1 小时）
日志内容	请求用户、操作类型、资源新旧版本、策略决策	资源当前状态、策略违规详情、合规评分
日志用途	实时审计、事件溯源、回滚决策	合规报告、历史趋势、存量风险发现
性能影响	中等（增加 API 请求延迟）	低（后台异步执行）
回滚护栏适用性	核心：拦截并记录每一次危险变更	辅助：发现未受保护的存量资源

3.6 关键要点总结

策略是规则的集合：一个 ClusterPolicy 可包含多个 Rule，每个 Rule 独立匹配资源并执行动作。
Match/Exclude 是策略的“门”：精确控制策略生效范围，避免误拦截。回滚护栏应使用 match 定位关键资源，使用 exclude 放行系统组件或管理员。
Validate + deny 是回滚护栏的核心：通过 deny 条件表达式，可以基于请求操作（CREATE/UPDATE/DELETE）、资源标签、注解甚至用户信息做出拒绝决策。
Mutate 用于“打标记”：在资源创建时自动注入回滚保护标签，确保后续 Validate 策略能够识别。
Admission 控制是审计日志的主要来源：每次策略评估都会生成包含请求上下文和决策结果的日志条目，这是回滚审计的基础。