在 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 作为 sidecar）	极低（本地调用）	独立于中心服务	中（需要 sidecar 注入和管理）	K8s 中大规模微服务
中心化服务（OPA 作为独立服务）	低（网络 RTT）	单点，需要高可用	低	中小规模或者非 K8s 部署
编译嵌入（Cedar WASM）	极低（进程内调用）	与应用同进程	低	语言生态支持 WASM 的场景
API 服务（OpenFGA/SpiceDB）	中（网络 RTT + 图查询）	单点，需要高可用	低-中	Zanzibar 式关系授权方案

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

维度	OPA Rego	Cedar
语言风格	逻辑编程（Datalog-like）	结构化自然语言
学习曲线	陡（对没有逻辑编程背景的工程师）	缓（写法接近条件表达式）
执行方式	Go 引擎解释执行 + WASM 编译	Rust 引擎 → WASM 编译，嵌入应用
类型安全	弱（Rego 是动态类型）	强（Cedar schema 提供编译期类型检查）
策略结构	单包，多规则	多策略，每个策略独立
测试支持	opa test	cedar test (CLI)
生态	CNCF Graduated，Istio/K8s/Kong 广泛集成	AWS 生态，Verified Permissions 集成

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 多租户权限设计

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-06-12 · architecture / security

【零信任安全架构】零信任策略引擎：OPA/Rego 与 Cedar 在 ZT 中的落地

在零信任架构中，策略引擎（PDP）是每次访问决策的裁判——不仅要回答'这个人能不能访问这个资源'，还要回答'在当前设备姿态、地理位置、时间上下文下，这个人能不能访问这个资源'。本文聚焦策略引擎在零信任场景中的额外要求：多维输入的协同、策略的实时更新、冲突检测和策略即代码的 CI/CD。

2026-06-17 · architecture / security

【身份与访问控制工程】RBAC、ABAC、ReBAC：权限模型怎么选

RBAC 简单但会角色爆炸，ABAC 灵活但策略管理失控时更可怕，ReBAC 表达力强但引入了图遍历的性能约束。三种模型不是'选一个升级另一个'的线性关系，而是在表达能力、管理成本和性能三者之间做工程权衡。本文从每种模型的本质数据结构出发，拆解选型框架。

2026-06-13 · architecture / security

【身份与访问控制工程】IAM 全景：为什么这是高价值赛道

从 2020 年 SolarWinds 到 2024 年 Okta 支持系统泄露，身份基础设施的安全失败反复证明一件事：IAM 不是 IT 支撑系统，而是安全架构的承重墙。本文建立现代 IAM 的全景地图——从认证协议、令牌体系、权限模型到身份治理与平台选型，给出 5 个贯穿全系列的核心问题。

2026-06-18 · architecture / security

【身份与访问控制工程】Zanzibar 风格权限系统：Google 的全球授权引擎

Google Zanzibar 论文在 2019 年发布后，引发了开源授权系统的一波重新设计：Auth0 FGA、SpiceDB、Permify、Ory Keto——全都基于 Zanzibar 的'关系图+命名空间配置'模型。但论文本身只讲了 What，没深入 Why。本文从 Zanzibar 的 relation tuple 模型、namespace config 的语义、consistency 模型（Zookie）和工程权衡出发，拆解为什么 Zanzibar 的设计决策是这样的，以及你自己实现时要面对什么。