3. 日志平台组件拓扑模型

在构建 OPA 策略集成测试环境之前，必须首先明确日志平台的核心组件、服务间依赖关系以及数据流路径。本章定义的标准拓扑模型将作为后续权限规则注入与验证的基准环境。

3.1 核心组件定义

日志平台采用经典的 ELK 技术栈，并引入消息队列与边车采集器以增强可观测性与策略执行点。下表列出各组件的功能角色与 OPA 策略集成点：

3.2 服务间依赖关系

组件之间的依赖关系决定了数据流转的先后顺序与策略执行时机。下图以有向图形式展示核心依赖：

3.3 数据流路径

一条典型的日志记录从产生到展示，会经过以下 6 个阶段。每个阶段都可能触发 OPA 策略检查：

1. 采集阶段： Filebeat 监听日志文件变化，读取新行并添加元数据（host、timestamp）。
2. 解析阶段： Fluentd 根据配置的 parser 插件（如 regexp、json、ltsv）将原始文本转为结构化事件。
3. 缓冲阶段： 结构化事件被序列化后发送到 Kafka 指定 topic，等待下游消费。
4. 过滤阶段： Logstash 从 Kafka 拉取事件，执行 filter 插件链（grok、mutate、geoip），并在此处调用 OPA 进行合规判定。
5. 存储阶段： 合规事件通过 bulk API 写入 Elasticsearch 索引；OPA 在此处校验索引名称、字段映射与写入权限。
6. 展示阶段： Kibana 发起查询请求，Elasticsearch 返回结果；OPA 对查询 DSL 进行安全审计，防止数据泄露。

以下 SVG 展示了完整的数据流路径，并标注了 OPA 策略执行点：

3.4 拓扑配置清单

在测试环境中，各组件的连接配置需保持一致。以下为 Fluentd 到 Kafka 的典型输出配置示例：

# fluentd.conf - 输出到 Kafka
<match logstash.**>
  @type kafka2
  brokers kafka-1:9092,kafka-2:9092,kafka-3:9092
  topic_key topic
  default_topic opa-logs
  required_acks -1
  <format>
    @type json
  </format>
  <buffer>
    @type file
    path /var/log/fluentd/buffer/kafka
    flush_interval 5s
  </buffer>
</match>

Logstash 从 Kafka 消费并调用 OPA 的 pipeline 配置：

# logstash.conf - 从 Kafka 消费并调用 OPA
input {
  kafka {
    bootstrap_servers => "kafka-1:9092,kafka-2:9092"
    topics => ["opa-logs"]
    codec => json
  }
}
filter {
  # 调用 OPA 进行合规检查
  http {
    url => "http://opa-sidecar:8181/v1/data/logs/compliance"
    verb => "POST"
    body => '{"input": {"event": "%{message}", "source": "%{host}"}}'
    target_body => "opa_result"
  }
  if [opa_result][allow] == false {
    drop { }
  }
}
output {
  elasticsearch {
    hosts => ["https://es-1:9200", "https://es-2:9200"]
    index => "opa-logs-%{+YYYY.MM.dd}"
    user => "logstash_writer"
    password => "${ES_PWD}"
    ssl => true
  }
}