4. OPA（Open Policy Agent）概述：OPA架构、Rego语言简介、OPA与Kubernetes的集成方式
在构建多租户故障域隔离体系时，策略执行引擎是保障租户边界不被突破的核心组件。OPA（Open Policy Agent）作为云原生计算基金会（CNCF）的毕业项目，提供了一套统一的、上下文感知的策略引擎，能够将策略从具体的业务逻辑中解耦出来，实现策略即代码（Policy as Code）。本章将深入剖析OPA的架构设计、其专属策略语言Rego的核心语法，以及OPA与Kubernetes的三种主流集成模式。
4.1 OPA架构：解耦策略决策与执行
OPA的核心设计哲学是策略决策与策略执行分离。它本身不负责执行具体的操作（如拒绝Pod创建、关闭端口），而是作为一个决策引擎，接收外部的查询请求，基于加载的策略和数据，返回决策结果。这种架构使得策略管理变得集中、可审计且与基础设施无关。
4.2 Rego语言简介：声明式策略即代码
Rego 是专为 OPA 设计的声明式查询语言，灵感来源于 Datalog。它允许你以高度可读的方式定义“如果……那么……”的规则。Rego 的核心是规则（Rules）和查询（Queries）。
4.2.1 Rego 核心概念
- 文档模型：OPA 将所有输入和输出都视为嵌套的 JSON 文档。Rego 规则本质上是在定义新的文档（虚拟文档）。
- 规则（Rules）：分为完整规则（Complete Rules）和部分规则（Partial Rules）。完整规则为某个文档赋予一个值；部分规则定义一组条件，满足时文档为真。
- 迭代与推导：Rego 使用
some关键字进行迭代，通过逻辑推导而非循环来遍历集合。
4.2.2 典型 Rego 策略示例
以下是一个用于多租户场景的准入控制策略，要求所有 Pod 必须包含租户标签，且不能调度到其他租户的节点上。
package kubernetes.admission
import data.tenants
# 规则：拒绝缺少租户标签的 Pod
deny[msg] {
input.request.kind.kind == "Pod"
not input.request.object.metadata.labels["tenant-id"]
msg := "Pod 必须包含 tenant-id 标签"
}
# 规则：拒绝 Pod 调度到非本租户的节点
deny[msg] {
input.request.kind.kind == "Pod"
pod_tenant := input.request.object.metadata.labels["tenant-id"]
node_selector := input.request.object.spec.nodeSelector["tenant-id"]
pod_tenant != node_selector
msg := sprintf("Pod 的租户 %v 与节点选择器指定的租户 %v 不匹配", [pod_tenant, node_selector])
}opa eval 命令配合 --data 和 --input 参数可以快速测试策略。例如：opa eval --data policy.rego --input input.json "data.kubernetes.admission"。
4.3 OPA与Kubernetes的集成方式
OPA 与 Kubernetes 的集成主要有三种模式，分别适用于不同的场景和粒度。下表对比了这三种方式的适用场景与特点。
| 集成方式 | 核心组件 | 决策时机 | 适用场景 | 性能影响 |
|---|---|---|---|---|
| Admission Controller | OPA Gatekeeper / kube-mgmt | 资源创建/更新时 | 资源合规校验、租户隔离策略 | 中等（同步调用） |
| Sidecar / 代理 | OPA-Envoy 插件 / 自定义 Sidecar | 运行时请求处理 | 服务间访问控制、API 鉴权 | 低（异步/缓存） |
| 外部决策点 | OPA REST API | 按需查询 | CI/CD 策略检查、审计日志分析 | 低（非实时） |
4.3.1 方式一：Admission Controller（准入控制器）
这是最常用的集成方式，尤其适用于多租户故障域隔离。通过部署 OPA Gatekeeper，可以将 Rego 策略转化为 Kubernetes 的 ValidatingAdmissionPolicy 或 MutatingAdmissionPolicy。当用户提交资源（如 Pod、Service）时，Kubernetes API Server 会调用 Gatekeeper 的 Webhook 进行校验。
- 优势：原生集成，策略生效在资源持久化之前，能有效阻止不合规资源的创建。
- 劣势：仅覆盖资源创建/更新阶段，无法控制运行时行为。
4.3.2 方式二：Sidecar / 代理模式
在服务网格（如 Istio）或自定义 Sidecar 中集成 OPA，可以实现对服务间通信的细粒度访问控制。OPA 作为 Sidecar 的一部分，拦截进出 Pod 的流量，根据 Rego 策略做出允许或拒绝的决策。
- 优势：覆盖运行时流量，可以实现基于请求内容（如 HTTP 方法、路径、JWT Claims）的精细控制。
- 劣势：部署复杂度增加，每个 Pod 都需要注入 Sidecar。
4.3.3 方式三：外部决策点（REST API）
OPA 本身暴露了 REST API（/v1/data），任何系统都可以直接调用它进行策略查询。这种方式常用于 CI/CD 流水线中的合规检查，或作为审计系统的决策引擎。
- 优势：解耦最彻底，任何语言和框架都可以集成。
- 劣势：需要外部系统自行处理调用逻辑和错误重试。