【身份与访问控制工程】OPA、Cedar 与策略引擎落地

在 RBAC、ABAC、ReBAC 怎么选 中讨论了权限模型，在 Zanzibar 中讨论了图关系授权。但这些都回答的是”授权逻辑应该怎么表达”。策略引擎（Policy Engine）回答的是”授权逻辑应该在哪里执行、怎么管理、怎么测试”。

OPA（Open Policy Agent，CNCF Graduated 项目）是当前策略引擎的事实标准。AWS 在 2023 年开源的 Cedar 提供了另一种设计哲学。本文以两者的对比为主线，拆解策略引擎的架构模式和工程落地。

一、策略引擎的架构模式

flowchart TD
  subgraph "Sidecar 模式"
    App1["Application"] -->|"Policy Query"| OPA1["OPA Sidecar"]
    OPA1 -->|"Data Sync"| Bundle["Bundle Server<br/>(S3 / OCI Registry)"]
  end

  subgraph "中心化服务模式"
    App2["Application"] -->|"Policy Query"| OPA-Central["OPA Central Service"]
  end

  subgraph "编译嵌入模式 (Cedar)"
    App3["Application"] -->|"WASM Call"| CedarWASM["Cedar WASM<br/>(嵌入式)"]
  end

  subgraph "API 服务模式 (OpenFGA)"
    App4["Application"] -->|"gRPC/REST"| OpenFGA["OpenFGA Server"]
  end

四种模式的权衡：

Sidecar 模式下，OPA 的策略和数据的更新通过 Bundle 机制——OPA 定期从 Bundle Server（S3 / OCI Registry / HTTP Server）拉取最新的策略和数据。这避免了每次策略更新都要重启 OPA 或应用。

二、OPA / Rego：策略语言的工程现实

2.1 Rego 的核心语义

Rego 不是过程式语言——它是类 Datalog 的声明式策略语言，基于”查询评估”（Query Evaluation）模型。

package iam.authz

import rego.v1

# 数据：用户属性
user_attributes := {
    "zhangsan": {"department": "engineering", "clearance": 3},
    "lisi": {"department": "hr", "clearance": 1}
}

# 策略规则
default allow := false

allow if {
    input.user == input.resource.owner
}

allow if {
    attr := user_attributes[input.user]
    attr.department == "engineering"
    attr.clearance >= 2
    input.action in ["read", "write"]
}

关键语义： - 规则求值是”搜索满足条件的所有解”——不只是 Bool。allow 规则可以有多个满足条件的分支。 - default allow := false：默认拒绝——如果没有任何规则体的条件被满足，allow 为 false。 - input：查询请求的 JSON 输入（{"user": "zhangsan", "action": "read", "resource": {...}}）。 - 变量绑定：attr := user_attributes[input.user] 是变量绑定，不是赋值。Rego 没有变量重新赋值——所有变量绑定在规则体内必须保持一致。

2.2 Rego 的性能瓶颈

Rego 的策略求值是 O(n) 的——每个查询都需要求值所有规则。但这是 O(规则数量)，不是 O(数据规模)：

• 规则数量：通常几十到几百条，单次求值 0.1-5ms。
• 数据规模：如果策略中引用了 data. 开头的外部数据（如 data.users.all[input.user]），数据量大会拉低性能。

优化关键： 1. 将数据查询推到策略引擎之外——在调用 OPA 前已经完成了数据库查询，OPA 的 input 中包含的是精炼后的数据。 2. 避免在规则中使用大循环——Rego 没有 for 循环，但 [k | some k; condition] 这种推导式（comprehension）会对集合中的每个元素求值条件，等价于循环。

工程陷阱：很多人把 OPA 当成”可以在里面查数据库”的工具——通过 data. 前缀引入外部数据源，然后在大集合上做 Rego 逻辑。这在百级记录时可行，在万级记录时 p99 延迟会超过 100ms，在百万级记录时直接用不完一个 HTTP 请求的超时。OPA 的设计意图是”策略求值”，不是”数据处理引擎”。

三、Cedar：AWS 的方案

Cedar（GitHub）是 AWS 在 2023 年开源的新策略引擎，与 Amazon Verified Permissions（AWS 的托管 Zanzibar 式授权服务）配套，也作为独立的授权引擎提供。

3.1 Cedar 的设计取舍 vs OPA

Cedar 的策略语法示例：

permit(
    principal == User::"zhangsan",
    action == Action::"readDocument",
    resource == Document::"readme.txt"
)
when {
    resource.isPublic == true ||
    principal.department == resource.department
};

Cedar 的策略模型是独立策略，不是规则体——每条策略是一个完整的”允许/禁止”声明。多条策略之间取”允许的并集”，显式的 forbid 策略覆盖 permit 策略。

3.2 Cedar 的优势与局限

优势： - Schema 驱动的类型检查——在策略编写阶段就能发现类型错误（如引用了不存在的操作）。 - 基于 Rust WASM 编译，嵌入应用时性能稳定且不与主机语言的 GC 交互。 - 策略语法对非工程师（安全合规团队、法务）友好。

局限（截至 2026 年）： - 生态远小于 OPA——没有 Istio/K8s Admission Control 的现成集成，没有 Bundle Server 等配套基础设施。 - 策略必须绑定到特定 Principal/Action/Resource 三元组——不适用于”处理所有请求”的通用模式（如 Envoy 的外部授权过滤器需要 OPA 那种通用 input 解析能力）。 - 策略管理的规模化经验（数百条策略、多团队、多服务）还在社区形成中。

四、策略即代码（Policy as Code）：CI/CD 中的策略管理

无论是 OPA 还是 Cedar，策略文件（.rego 或 .cedar）都应该进 Git，走 CI/CD pipeline。

flowchart LR
    Git["Git PR"] -->|"push"| CI["CI Pipeline"]
    CI -->|"opa test / cedar test"| UnitTest["Unit Test: 策略逻辑"]
    CI -->|"conftest / 自定义脚本"| IntegrationTest["Integration Test: 真实请求 vs 策略"]
    CI -->|"fmt / lint"| Lint["Rego Fmt / Cedar Format"]
    CI -->|"review"| Approve["策略 Review 门禁"]
    CI --> Bundle["Bundle Build"]
    Bundle --> Deploy["部署到 Bundle Server / OP 服务"]

工程实践建议： 1. 策略文件的测试和数据（如 input 的 mock）放在同仓库，保证 CI 中可独立运行。 2. opa test 支持 table-driven test——每个 test case 一个 JSON/YAML 文件，定义 input 和 expected output。 3. 生产策略变更走完整的 PR review（至少一名安全工程师 approve）。 4. 策略的灰度发布：不是一次性全量部署，而是通过 Bundle Server 的 tag/version 机制实现”部分服务先更新策略”，验证后再全量。

上一篇：Zanzibar 风格权限系统 下一篇：B2B SaaS 多租户权限设计