2. OPA 基础回顾：OPA 架构、Rego 语言核心语法、OPA 与 Kubernetes 集成方式
在深入节点池安全基线巡检之前，必须牢固掌握 OPA（Open Policy Agent）的核心基础。本章将系统回顾 OPA 的架构设计、Rego 策略语言的核心语法，以及 OPA 与 Kubernetes 的三种主流集成模式。这些知识是后续编写合规巡检策略的基石。
2.1 OPA 架构：策略解耦与决策引擎
OPA 是一个通用的、开源的策略引擎，其核心设计理念是将策略决策与业务逻辑完全解耦。OPA 本身不执行任何操作，它只负责根据输入数据和策略规则，输出一个“是/否”或结构化的决策结果。
- 服务（Service）： 需要执行策略决策的外部系统，如 Kubernetes API Server、Envoy、CI/CD 系统。
- OPA Agent： 核心引擎，包含 Rego 策略、数据文档和决策缓存。
- Rego 策略： 用 Rego 语言编写的规则集合，定义了“允许”或“拒绝”的逻辑。
- 数据文档（Data Document）： 外部加载的 JSON/YAML 数据，如 Kubernetes 资源清单、集群配置、黑名单等。
- 输入文档（Input Document）： 每次策略查询时由服务传入的临时数据，如待审批的 Pod 创建请求。
2.2 Rego 语言核心语法
Rego 是专为 OPA 设计的声明式查询语言，灵感来源于 Datalog。它不描述“如何做”，而是描述“数据应该是什么样子”。
2.2.1 基础结构与规则
一个 Rego 文件通常包含 Package 声明和若干 Rule。规则分为默认规则、完整规则和部分规则。
package kubernetes.admission
# 默认规则：默认拒绝所有请求
default allow = false
# 完整规则：如果满足条件，则允许
allow {
input.request.operation == "CREATE"
input.request.kind == "Pod"
input.request.namespace == "production"
}
# 部分规则：返回一个集合
deny[msg] {
input.request.operation == "DELETE"
msg := sprintf("不允许删除命名空间 %v 中的资源", [input.request.namespace])
}2.2.2 常用内置函数与迭代
Rego 提供了丰富的内置函数用于字符串处理、集合操作、时间比较等。迭代通过 some 关键字或隐式变量实现。
| 类别 | 函数/语法 | 说明 | 示例 |
|---|---|---|---|
| 集合操作 | count() |
计算集合元素数量 | count(input.request.object.spec.containers) > 1 |
| 字符串匹配 | startswith() |
检查字符串前缀 | startswith(input.request.name, "prod-") |
| 正则匹配 | re_match() |
正则表达式匹配 | re_match("^[a-z]+$", input.request.name) |
| 迭代 | some i; ... |
遍历数组或集合 | some i; input.request.object.spec.containers[i].image == "nginx:latest" |
| 数据查询 | data.somepath |
访问加载的外部数据 | data.allowed_registries[_] == image_registry |
2.2.3 完整规则 vs 部分规则
理解这两种规则的区别，是编写复杂策略的关键。
| 特性 | 完整规则 (Complete Rule) | 部分规则 (Partial Rule) |
|---|---|---|
| 返回值 | 单个布尔值或标量 | 集合（Set）或对象（Object） |
| 定义方式 | allow { ... } |
deny[msg] { ... } |
| 典型用途 | 全局准入控制（允许/拒绝） | 生成多条拒绝原因或审计日志 |
| 多条件逻辑 | 所有条件必须同时满足（AND） | 每个独立条件生成一个结果（OR） |
x := 1; x := 2 会导致编译错误。正确的做法是使用 some 或创建新变量。
2.3 OPA 与 Kubernetes 集成方式
OPA 与 Kubernetes 的集成主要有三种模式，每种模式适用于不同的场景。在节点池安全基线巡检中，我们主要使用 Admission Controller 模式。
2.3.1 模式一：Admission Controller（Kubernetes 原生集成）
这是最常用、最强大的集成方式。OPA 以 ValidatingAdmissionWebhook 的形式注册到 Kubernetes API Server。当有资源创建、更新或删除请求时，API Server 会并行调用 OPA 进行策略评估。
- 优点： 实时拦截，强制合规，原生支持 Kubernetes 资源。
- 缺点： 增加 API Server 延迟（通常 < 5ms），需要管理 Webhook 证书。
- 代表项目： OPA Gatekeeper（本课程核心工具）。
2.3.2 模式二：Sidecar / 代理模式
OPA 作为 Sidecar 容器或独立代理运行在每个 Pod 或节点上。应用程序通过本地 HTTP 接口向 OPA 查询策略决策。这种模式延迟极低，适合对性能敏感的微服务场景。
- 优点： 低延迟，不依赖集群级组件，适合边缘决策。
- 缺点： 策略分发和管理相对复杂，每个服务实例都需要部署 OPA。
- 适用场景： 服务网格（Envoy + OPA）、应用级授权。
2.3.3 模式三：CLI / 审计模式
通过 opa eval 或 opa test 命令，在 CI/CD 流水线或本地环境中离线执行策略检查。这种模式不拦截实时请求，而是对已有的资源清单或集群快照进行批量合规审计。
- 优点： 无运行时开销，适合大规模历史数据审计，易于集成到 GitOps 流程。
- 缺点： 非实时，无法阻止违规操作发生。
- 适用场景： 夜间合规巡检、上线前策略验证、安全事件回溯。