2. OPA 基础概念

在深入节点池配置巡检与审计方案之前，必须先理解 OPA（Open Policy Agent）的核心原理。OPA 是一个开源的、通用的策略引擎，它将策略与业务逻辑解耦，使得安全与合规规则可以独立声明、统一执行。本章将系统介绍 OPA 的本质、Policy-as-Code 理念、Rego 语言基础以及 OPA 与 Kubernetes 的集成方式。

2.1 OPA 是什么

OPA（Open Policy Agent）是一个由 CNCF 孵化的开源策略引擎，用于在云原生环境中实现统一的策略决策。它不负责执行策略（如阻止 Pod 创建），而是负责回答“是否允许某个操作”的问题。OPA 将策略从应用程序代码中剥离出来，作为独立服务运行，任何需要策略决策的系统都可以通过 REST API 或 Sidecar 方式向其查询。

2.2 Policy-as-Code 理念

Policy-as-Code（策略即代码）是将安全、合规、治理规则以代码形式声明、版本化、测试和自动部署的实践。它打破了传统策略管理依赖文档、邮件或人工审批的局限，使策略具备与应用程序代码同等的工程化能力。

Policy-as-Code 的核心优势在于：可审计（每条策略变更都有记录）、可重复（相同输入永远得到相同决策）、可自动化（无需人工介入即可执行合规检查）。

2.3 Rego 语言简介

Rego 是 OPA 的原生策略语言，专为在复杂嵌套数据结构（如 JSON、YAML）上进行策略决策而设计。Rego 基于 Datalog 逻辑编程范式，使用声明式查询而非命令式逻辑。这意味着你只需描述“策略应该是什么”，而不需要描述“如何检查策略”。

以下是一个简单的 Rego 策略示例，用于检查节点池的实例类型是否在允许列表中：

package node_pool_compliance

# 允许的实例类型列表
allowed_instance_types := {"Standard_D4s_v3", "Standard_D8s_v3", "Standard_D16s_v3"}

# 默认规则：拒绝
default allow := false

# 规则：如果节点池的实例类型在允许列表中，则允许
allow {
    input.spec.instanceType == allowed_instance_types[_]
}

# 违规报告：当 allow 为 false 时，生成详细原因
violation[{"msg": msg}] {
    not allow
    msg := sprintf("节点池 '%s' 的实例类型 '%s' 不在允许列表中", [input.metadata.name, input.spec.instanceType])
}

Rego 的查询结果永远是 JSON 格式，这使得它天然适合与 Kubernetes API 对象、云服务商 SDK 返回的数据结构对接。

2.4 OPA 与 Kubernetes 的集成方式

OPA 与 Kubernetes 的集成主要通过 OPA Gatekeeper 项目实现。Gatekeeper 是一个基于 OPA 的 Kubernetes 专用准入控制器和策略引擎，它利用 Kubernetes 的 Admission Webhook 机制拦截资源创建、更新请求，并向 OPA 查询策略决策。

集成架构包含三个核心组件：

1. OPA Gatekeeper 控制器：部署在集群中的 Pod，负责管理策略的生命周期（安装、更新、删除）。
2. ConstraintTemplate：定义策略的“骨架”，包括参数 schema 和 Rego 代码模板。用户通过实例化 ConstraintTemplate 来创建具体策略。
3. Constraint：策略的具体实例，指定参数值（如允许的实例类型列表）并关联目标资源类型（如 NodePool）。

在节点池配置巡检场景中，OPA Gatekeeper 的工作流程如下：

• 策略定义：通过 ConstraintTemplate 定义 Rego 策略模板，例如“节点池实例类型必须在白名单内”。
• 策略实例化：创建 Constraint 资源，指定参数（如白名单列表）并绑定到 NodePool 资源类型。
• 实时拦截：当运维人员创建或更新节点池时，API Server 调用 Gatekeeper Webhook，OPA 引擎执行策略并返回决策。
• 审计模式：Gatekeeper 支持 dryrun 枚举模式，只记录违规而不实际拒绝，适合策略上线前的验证阶段。