OPA与资源模型协同日志平台组件拓扑权限设计 - 第1节

1.1 背景：云原生日志平台面临的权限碎片化挑战

在云原生环境中，日志平台通常由多个异构组件构成：采集器（Fluentd / Filebeat）、缓冲队列（Kafka）、流处理器（Flink）、存储引擎（Elasticsearch / S3）以及可视化层（Grafana / Kibana）。每个组件都有自己的资源模型和权限控制机制，导致以下核心痛点：

• 权限模型割裂：Kafka 用 ACL 控制 Topic 读写，Elasticsearch 用 RBAC 控制索引权限，Grafana 用组织/文件夹权限控制仪表盘。运维人员需要在多个系统间重复配置，极易出现遗漏或冲突。
• 资源拓扑不透明：一条日志从采集到存储，经过多个中间件，但缺乏统一的资源拓扑视图。当需要限制某个业务线只能访问自己的日志时，无法在全局层面声明“日志流 → 索引 → 仪表盘”的关联关系。
• 策略审计困难：每个组件的策略格式不同（JSON / YAML / 数据库记录），审计人员无法通过单一查询了解“谁对哪些日志资源拥有什么权限”。

1.2 目标：构建统一、可审计、拓扑感知的权限体系

本课程旨在通过 OPA（Open Policy Agent） 与 资源模型（Resource Model） 的协同，为日志平台组件拓扑设计一套统一的权限控制方案。具体目标如下：

1.3 整体架构概览

本方案采用“资源模型驱动 + OPA 策略执行 + 拓扑同步器”的三层架构。下图展示了核心组件及其交互关系：

1.4 核心组件与职责

架构中的每个组件承担明确的职责，下表详细说明：

1.5 权限决策流程

当用户或组件发起资源访问请求时，系统按以下步骤执行权限决策：

1. 请求拦截：组件拓扑层的 Sidecar 或 API 网关拦截请求，提取用户身份、目标资源、操作类型。
2. 资源解析：查询资源模型，将目标资源解析为拓扑路径（如：logstream:app-nginx → index:nginx-2025-01 → dashboard:nginx-overview）。
3. 策略评估：将请求上下文和资源拓扑路径发送给 OPA，OPA 根据预加载的 Rego 策略进行决策。
4. 决策执行：OPA 返回 allow 或 deny，组件根据决策放行或拒绝请求。
5. 审计记录：将决策上下文（时间、用户、资源路径、策略版本、决策结果）写入审计日志。

1.6 与现有方案的对比

下表将本方案与传统 RBAC 和组件自建 ACL 方案进行对比：

1.7 本章小结