📚 课程目录第3章策略即代码概述

3. 策略即代码概述：OPA、Rego、Kyverno 等策略引擎介绍、策略代码化与版本管理

在“升级窗口演练灰度批次”场景中，传统人工审批与静态配置已无法满足动态、多集群、多租户的安全合规要求。策略即代码（Policy as Code, PaC）将安全与合规规则以声明式代码的形式嵌入 CI/CD 与运行时管控，实现审计日志的自动化、可复现、可版本追溯。本章聚焦三大主流引擎——OPA、Rego、Kyverno，并阐述策略代码化与版本管理的最佳实践。

3.1 策略即代码核心价值

策略即代码将原本写在 Wiki、审批单或人工脑中的规则，转化为机器可执行的代码。其核心价值包括：

自动化执行：策略在部署前、部署中、运行时自动评估，无需人工介入。
版本可追溯：策略代码与业务代码一同纳入 Git，每次变更都有完整审计记录。
一致性：同一套策略可跨环境（开发、测试、生产）无差别执行。
可测试性：策略代码可编写单元测试，确保规则逻辑正确。

  灰度批次场景映射：在升级窗口演练中，策略即代码可定义“灰度批次不得超过 20% 节点”、“金丝雀发布必须通过健康检查”、“变更窗口仅限 UTC 时间 02:00-04:00”等规则，所有评估结果自动写入审计日志。

3.2 主流策略引擎对比

当前业界最成熟的策略引擎包括 OPA（Open Policy Agent）、Kyverno 以及底层策略语言 Rego。下表从多个维度进行对比：

维度	OPA + Rego	Kyverno
定位	通用策略引擎，独立于平台	Kubernetes 原生策略引擎
策略语言	Rego（声明式查询语言）	YAML 清单（无新语言）
部署模式	Sidecar / DaemonSet / 外部服务	Admission Webhook + 控制器
适用场景	K8s、Terraform、微服务 API、SQL	K8s 资源验证、变异、生成
审计日志	决策日志（JSON）可对接外部存储	内置 PolicyReport / ClusterPolicyReport
学习曲线	中高（需学习 Rego 语法）	低（YAML 即可）
版本管理	Rego 文件 + OPA bundle	YAML 文件 + GitOps

选型建议：若团队已采用 GitOps 且仅管控 K8s 资源，优先选择 Kyverno；若需要跨平台（如 Terraform、API 网关、K8s 混合）统一策略，选择 OPA + Rego。

3.3 OPA 与 Rego 深度解析

OPA 是一个开源的、通用的策略引擎，它将决策与执行分离。OPA 通过 Rego 语言表达策略，Rego 是一种受 Datalog 启发的声明式查询语言，擅长处理嵌套 JSON/YAML 数据。

3.3.1 Rego 策略示例

以下 Rego 策略定义：灰度批次中，节点数量不得超过集群总节点的 20%。

package upgrade_window

# 允许的最大灰度比例
max_gray_ratio := 0.2

# 默认拒绝
default allow = false

# 规则：灰度批次节点数 / 总节点数 ≤ 0.2
allow {
    total_nodes := input.cluster.total_nodes
    gray_nodes := input.gray_batch.node_count
    gray_nodes / total_nodes <= max_gray_ratio
}

# 审计日志输出：记录决策原因
audit_info = {
    "decision": allow,
    "reason": sprintf("灰度比例 %.2f，阈值 %.2f", [gray_nodes/total_nodes, max_gray_ratio])
}

  审计日志留痕关键点：Rego 策略中的 audit_info 对象可被 OPA 决策日志捕获，输出为结构化 JSON，包含决策结果、原因、输入摘要，直接对接 ELK 或 Splunk。

3.3.2 OPA 架构与审计流

下图展示 OPA 在升级窗口演练中的决策与审计日志链路：

3.4 Kyverno 原生策略引擎

Kyverno 是专为 Kubernetes 设计的策略引擎，无需学习新语言，策略以 YAML 清单定义。Kyverno 支持三种策略类型：

Validate：验证资源是否符合规则，拒绝不合规资源。
Mutate：在资源创建或更新时自动修改字段。
Generate：基于规则自动生成新资源（如 Namespace 配额）。

3.4.1 Kyverno 策略示例

以下策略确保灰度批次中所有 Pod 必须带有 audit.gray-batch/id 标签：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-gray-batch-label
spec:
  validationFailureAction: Audit   # Audit 模式仅记录，不拒绝
  rules:
  - name: check-gray-batch-label
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "灰度批次 Pod 必须包含标签 'audit.gray-batch/id'"
      pattern:
        metadata:
          labels:
            audit.gray-batch/id: "?*"

审计模式 vs 强制模式：在升级窗口演练初期，建议使用 validationFailureAction: Audit，仅生成审计日志而不阻断部署，待策略稳定后再切换为 Enforce。

3.4.2 Kyverno 审计报告

Kyverno 自动生成 PolicyReport 和 ClusterPolicyReport 自定义资源，记录每条策略的评估结果：

apiVersion: wgpolicyk8s.io/v1alpha2
kind: PolicyReport
metadata:
  name: gray-batch-report
  namespace: upgrade-window
results:
- policy: require-gray-batch-label
  rule: check-gray-batch-label
  resource:
    apiVersion: v1
    kind: Pod
    name: gray-pod-7f8b9c
  status: fail
  severity: high
  message: "灰度批次 Pod 必须包含标签 'audit.gray-batch/id'"

3.5 策略代码化与版本管理

策略即代码的核心实践是将策略文件纳入 Git 仓库，与业务代码同生命周期管理。以下是推荐的工作流：

策略仓库结构：按环境（dev/staging/prod）和策略类型（validate/mutate/generate）组织目录。
版本控制：使用 Git 标签（v1.0.0, v1.1.0）标记策略版本，与升级窗口演练版本对应。
CI 流水线：策略变更时自动运行单元测试（Rego 测试或 Kyverno CLI 测试），通过后合并到主分支。
策略分发：OPA 使用 Bundle API 从 Git 拉取策略；Kyverno 通过 GitOps 工具（ArgoCD/Flux）同步。
审计追溯：每次策略变更的 Git commit 信息、作者、时间戳均作为审计元数据，与决策日志关联。

常见陷阱：策略代码与业务代码分离管理会导致版本不匹配。建议在业务仓库中通过 Git Submodule 或 OPA Bundle 引用策略版本，确保灰度批次演练时策略版本与业务版本一致。

3.6 策略即代码在灰度批次中的审计价值

将策略代码化后，审计日志从“人工事后翻查”转变为“自动化实时留痕”：

不可抵赖性：每条策略评估结果都包含输入快照、决策时间、策略版本，无法篡改。
可复现性：给定相同输入和策略版本，可复现完全相同的决策结果。
可查询性：结构化日志（JSON/YAML）可直接被审计工具（如 Elasticsearch、Splunk）索引。