3. OPA（Open Policy Agent）入门：OPA架构、Rego策略语言基础、OPA部署模式

在云原生安全体系中，策略即代码（Policy as Code）是实现自动化合规与准入控制的核心思想。Open Policy Agent（OPA） 作为 CNCF 毕业项目，提供了一个统一、轻量级的策略引擎，能够将策略决策从具体业务逻辑中解耦。本章将深入 OPA 的架构设计、Rego 策略语言基础以及主流部署模式，为后续与控制平面集成打下坚实基础。

3.1 OPA 架构：决策解耦的核心设计

OPA 的核心架构遵循 决策请求（Query） 与 策略决策（Decision） 分离的原则。它本身不负责执行策略，而是作为一个独立的决策引擎，接收结构化输入（Input），结合策略规则（Policies）和数据（Data），输出允许/拒绝或更复杂的决策结果。

3.2 Rego 策略语言基础

Rego 是 OPA 的原生策略语言，受 Datalog 启发，专为表达复杂策略规则而设计。Rego 的核心是 规则（Rules） 和 查询（Queries），所有策略最终都归结为对数据的逻辑判断。

3.2.1 基本语法与结构

• 包（Package）： 每个 Rego 文件以 package 声明开头，用于组织策略命名空间。
• 规则（Rule）： 由头部（head）和体部（body）组成，体部包含一系列表达式，所有表达式为真时规则成立。
• 默认值（Default）： 使用 default 关键字为规则设置初始值，避免未定义错误。

package example.authz

# 默认拒绝所有请求
default allow = false

# 允许管理员访问
allow {
    input.role == "admin"
}

# 允许拥有特定资源的用户访问
allow {
    input.role == "user"
    input.resource == "read-only"
}

3.2.2 核心数据类型与操作符

3.2.3 完整策略示例：Kubernetes 准入控制

package kubernetes.admission

# 默认拒绝
default deny = false

# 拒绝特权容器
deny {
    input.request.operation == "CREATE"
    input.request.object.kind == "Pod"
    some container
    container := input.request.object.spec.containers[_]
    container.securityContext.privileged == true
}

# 拒绝挂载主机路径
deny {
    input.request.operation == "CREATE"
    input.request.object.kind == "Pod"
    some volume
    volume := input.request.object.spec.volumes[_]
    volume.hostPath != null
}

3.3 OPA 部署模式

OPA 支持多种部署模式，以适应不同的架构场景。选择哪种模式取决于性能要求、网络拓扑、数据同步策略以及运维复杂度。

3.3.1 部署模式对比

3.3.2 生产部署最佳实践

• 策略分层： 将通用策略（如禁止特权容器）与业务特定策略分离，便于维护和复用。
• 数据分发： 使用 OPA Bundle API 或配置管理工具（如 ConfigMap）定期同步策略和数据，避免决策不一致。
• 性能监控： 关注 OPA 决策延迟（p99 < 10ms 为佳），启用 OPA 内置的 Metrics 端点暴露 Prometheus 指标。
• 审计日志： 开启 OPA 的决策日志（Decision Logs），记录每次决策的输入、输出和策略版本，用于合规审计。
• 高可用： 独立服务模式建议部署多副本，并前置负载均衡；Sidecar 模式依赖 Kubernetes 调度保证。