4. 组件拓扑建模基础：节点、边、属性定义、拓扑图数据结构设计

在构建日志平台的安全权限模型之前，必须首先建立精确的组件拓扑图。拓扑图是策略引擎（OPA）评估访问路径、检测权限滥用、验证网络隔离的基础数据源。本章将定义拓扑图的三大核心要素：节点（Node）、边（Edge）、属性（Attribute），并设计标准化的数据结构。

4.1 节点（Node）：拓扑中的实体

节点代表日志平台中所有可被策略评估的资源实体。每个节点必须拥有全局唯一的标识符（ID）和明确的类型（Type）。

4.2 边（Edge）：实体间的关系

边定义了节点之间的有向关系。在安全权限建模中，边通常代表数据流、调用链或权限授予。每条边必须包含源节点（source）、目标节点（target）和关系类型（relation）。

4.3 属性（Attribute）：节点的元数据

属性为节点和边附加上下文信息，这些信息在 OPA 策略评估时作为 input 的一部分被引用。属性以键值对（Key-Value）形式存储。

// 节点属性示例（JSON 格式）
{
  "id": "pod:fluentbit-main-x1y2",
  "type": "pod",
  "attributes": {
    "namespace": "logging",
    "labels": {
      "app": "fluentbit",
      "version": "1.9"
    },
    "ip": "10.0.1.25",
    "service_account": "sa:fluentbit-sa",
    "security_context": {
      "run_as_non_root": true,
      "read_only_root_filesystem": true
    }
  }
}

// 边属性示例
{
  "source": "pod:fluentbit-main-x1y2",
  "target": "storage:s3-log-bucket",
  "relation": "writes_to",
  "attributes": {
    "protocol": "https",
    "port": 443,
    "encrypted": true,
    "rate_limit": "1000/s"
  }
}

4.4 拓扑图数据结构设计

为了支持 OPA 的高效查询，拓扑图数据采用邻接表（Adjacency List）结构存储。整体数据结构分为三个顶层字段：nodes、edges、metadata。

// 完整拓扑图数据结构（JSON Schema 风格）
{
  "metadata": {
    "version": "1.0",
    "environment": "production",
    "generated_at": "2025-04-10T08:00:00Z",
    "source": "topology-sync-controller"
  },
  "nodes": [
    {
      "id": "svc:log-collector",
      "type": "service",
      "attributes": {
        "namespace": "logging",
        "owner": "platform-team"
      }
    },
    {
      "id": "storage:es-prod-logs",
      "type": "storage",
      "attributes": {
        "type": "elasticsearch",
        "index_pattern": "logs-*",
        "access_level": "restricted"
      }
    }
  ],
  "edges": [
    {
      "source": "svc:log-collector",
      "target": "storage:es-prod-logs",
      "relation": "writes_to",
      "attributes": {
        "protocol": "http",
        "auth_method": "service-account"
      }
    }
  ]
}

4.5 拓扑图可视化：节点与边的关系

下图展示了一个简化的日志平台组件拓扑，包含采集、传输、存储、查询四个核心节点及其关系。

4.6 拓扑图在 OPA 中的使用方式

拓扑图数据通常以 data.topology 的形式加载到 OPA 的基础文档（Base Document）中。策略编写者可以通过 Rego 的 data.topology.nodes 和 data.topology.edges 进行遍历查询。

// Rego 策略示例：检查某个 Pod 是否有权限写入存储
package platform.logs

import future.keywords.in

# 查询拓扑中所有从指定 Pod 出发的 writes_to 边
allowed_targets[target] {
    some edge in data.topology.edges
    edge.source == input.pod_id
    edge.relation == "writes_to"
    target := edge.target
}

# 检查目标存储是否允许该 Pod 写入
allow_write {
    input.action == "write"
    input.target_storage in allowed_targets
}

4.7 拓扑图版本管理与增量更新

生产环境中，组件拓扑会频繁变化（Pod 扩缩容、服务升级、网络策略调整）。建议采用快照+增量补丁的策略：

• 全量快照：每 5 分钟生成一次完整拓扑，用于 OPA 冷启动和数据恢复。
• 增量补丁：每次拓扑变化时，仅推送变更的节点和边（add / remove / update），减少 OPA 数据加载开销。

// 增量补丁示例
{
  "patch": [
    {"op": "add", "path": "/nodes/-", "value": {"id": "pod:fluentbit-new", "type": "pod", "attributes": {...}}},
    {"op": "add", "path": "/edges/-", "value": {"source": "pod:fluentbit-new", "target": "storage:es-prod", "relation": "writes_to"}},
    {"op": "remove", "path": "/nodes/3"}  // 移除已下线的节点
  ]
}

4.8 拓扑图数据质量检查清单