WEBKT

基于 eBPF 与 Cilium Tetragon 构建企业级云原生安全审计方案

7 0 0 0

在 Kubernetes 动态调度和高度隔离的架构下，传统的基于主机内核模块（如 LKM）或系统调用拦截（如 ptrace/LD_PRELOAD）的安全审计方案面临着严峻的挑战。传统方案不仅性能开销大，而且容易被绕过，甚至可能因为内核模块崩溃导致整机宕机。

随着 eBPF（Extended Berkeley Packet Filter）技术的成熟，云原生安全迎来了变革。作为 Cilium 社区开源的运行时安全观测组件，Tetragon 基于 eBPF 实现了内核级的安全执行与审计，能够在几乎不影响系统性能的前提下，提供进程执行、文件读写、网络连接以及特权提升等维度的实时观测能力。

本文将分享如何基于 eBPF 和 Cilium Tetragon 构建一套企业级的云原生安全审计平台，解决海量容器环境下的动态审计与安全合规问题。

架构设计：从内核事件到安全合规

企业级云原生安全审计平台的核心诉求是：零侵入、低延迟、高可靠、可追溯。整体架构可以划分为四个层次：

+-------------------------------------------------------------+
|                     安全大盘 / 告警通道 / SIEM               |  展示与响应层
+-------------------------------------------------------------+
                               ^
                               | 告警/检索
+-------------------------------------------------------------+
|                ClickHouse / Elasticsearch / Loki            |  存储与分析层
+-------------------------------------------------------------+
                               ^
                               | 流式消费
+-------------------------------------------------------------+
|                  Kafka / Logstash / Vector                  |  传输与汇聚层
+-------------------------------------------------------------+
                               ^
                               | JSON/gRPC 日志
+-------------------------------------------------------------+
|       Tetragon DaemonSet (eBPF Probes + Agent)               |  内核采集层
+-------------------------------------------------------------+
                               ^
                               | Hook (sys_execve, sys_write)
+-------------------------------------------------------------+
|                        Linux Kernel                         |  基础设施层
+-------------------------------------------------------------+
  1. 内核采集层：在每个 K8s 节点上部署 Tetragon Agent（以 DaemonSet 方式运行）。eBPF 字节码在内核空间拦截敏感 syscall 并进行初步过滤，减少用户空间与内核空间的数据拷贝。
  2. 传输与汇聚层：Tetragon 将内核事件转化为结构化的 JSON 日志或 gRPC 流。通过高性能日志收集器（如 Vector 或 Fluent Bit）将数据实时推送到消息队列（Kafka）。
  3. 存储与分析层：利用 ClickHouse 存储结构化审计日志（ClickHouse 极度适合高吞吐的日志写入与多维检索），或者接入企业原有的 ELK/Loki 系统。
  4. 展示与响应层：结合 Grafana 进行可视化展示，并配置 Kibana/ClickHouse 告警规则，联动企业微信、钉钉或 Webhook 进行安全事件实时告警。

核心组件部署：Tetragon 落地实践

1. 部署 Tetragon 到 Kubernetes 集群

我们使用 Helm 进行高可用部署。由于需要加载 eBPF 探针，Tetragon 需要运行在特权模式，并挂载主机的 /sys/kernel/debug。

helm repo add cilium https://helm.cilium.io
helm repo update

# 创建命名空间并部署 Tetragon
helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.exportDirectory="/var/run/tetragon" \
  --set tetragon.prometheus.enabled=true

部署完成后，每个节点上都会启动一个 tetragon 实例。默认情况下，它会自动收集基础的进程执行事件（Process Execution）。

2. 定义安全审计策略（TracingPolicy）

Tetragon 的核心能力在于它的 TracingPolicy（追踪策略）。通过 CRD，我们可以定义在内核中拦截哪些系统调用（kprobes、tracepoints），以及如何进行参数过滤。

场景一：监控敏感文件写入（如 /etc/shadow 或 /etc/hosts）

在容器逃逸或入侵防御中，对敏感配置文件的修改是最致命的操作之一。以下策略用于审计对 /etc 目录下敏感文件的写操作：

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-sensitive-file-write
  namespace: kube-system
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      args:
        - index: 0
          type: "int" # dfd
        - index: 1
          type: "string" # filename
        - index: 2
          type: "int" # flags
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/etc/kubernetes/"
          matchActions:
            - action: Sigkill # 发现篡改行为，可直接在内核层发送 SIGKILL 阻断，也可仅做日志审计

场景二：审计非法进程拉起（例如在 Redis 容器中执行 whoami 或拉起 sh）

在合规审计中，生产环境的业务容器通常不应该运行 shell 交互命令。我们可以定义策略，一旦非研发命名空间的容器拉起了敏感 shell 进程，立即记录审计日志。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-container-shell-exec
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string" # filename
      selectors:
        - matchArgs:
            - index: 0
              operator: "Postfix"
              values:
                - "/bin/sh"
                - "/bin/bash"
                - "/usr/bin/nc"

管道建设：日志高效收集与清洗

Tetragon 默认将 JSON 日志写入宿主机的 /var/run/tetragon/tetragon.log。为了避免对节点磁盘造成冲击，推荐使用 Vector 将日志异步推送到 Kafka。

Vector 收集器配置示例

[sources.tetragon_logs]
  type = "file"
  include = ["/var/run/tetragon/tetragon.log"]
  read_from = "beginning"

[transforms.parse_tetragon]
  type = "remap"
  inputs = ["tetragon_logs"]
  source = '''
  # 解析 JSON 日志
  . = parse_json!(.message)
  
  # 提取关键 K8s 元数据，降低冷存储压力
  .audit_timestamp = .time
  .pod_name = .kubernetes.pod_name
  .namespace = .kubernetes.pod_namespace
  .container_name = .kubernetes.container_name
  .binary = .process_exec.process.binary
  .arguments = .process_exec.process.arguments
  '''

[sinks.kafka_out]
  type = "kafka"
  inputs = ["parse_tetragon"]
  bootstrap_servers = "kafka-cluster.logging:9092"
  topic = "k8s-security-audit"
  encoding.codec = "json"

通过这一管道，所有节点上发生的内核级敏感操作均被转换为轻量级、富含 K8s 上下文元数据的标准 JSON 结构，并汇聚到消息队列中。

企业落地痛点与调优经验

在生产环境下推广基于 eBPF 的审计方案，并非一帆风顺，需要重点解决以下三个“性能与稳定性”大坑：

1. 规避 eBPF Ring Buffer 丢包问题

在高并发、高 QPS 的业务场景下（例如高频拉起临时进程的 CI/CD 节点），Tetragon 产生的 eBPF 事件量极大。如果 Ring Buffer 队列满了，会导致日志丢失。

  • 调优手段：在 Helm Chart 中适当调大 tetragon.exportBufferSize 和内核缓冲区大小；同时，尽可能将过滤逻辑（如路径过滤、命名空间过滤）下沉到 eBPF 内核空间（即 TracingPolicy 的 selectors 中），避免在用户空间进行过滤。

2. 进程短期运行导致的 K8s 元数据丢失

由于 eBPF 捕获的是内核瞬间的 pid 变化，若容器内某个黑客脚本执行只需要 10 毫秒，当 Tetragon Agent 拿着 pid 去 K8s APIServer 或 Cgroup 路径查询 Pod 元数据时，该进程或容器可能已经销毁了。

  • 解决方案：Tetragon 引入了内置的 Cgroup 监听缓存。确保 Tetragon 优先使用本地缓存的 Cgroup 映射关系，而不是实时反查 APIServer。

3. 防范“阻断操作（Sigkill）”带来的业务副作用

Tetragon 的 TracingPolicy 支持在检测到违规行为时直接调用内核 SIGKILL 结束进程。这在安全演练中非常好用，但在生产环境必须保持克制。

  • 最佳实践：在生产环境，首期仅配置 action: Post（即仅记录日志并告警），经过至少两周的观察、白名单收敛后，再对高危行为（如向 /boot 写入、提权操作）开启 Sigkill 物理阻断。

结语

基于 eBPF 和 Cilium Tetragon 构建的安全审计系统，改变了以往“性能与安全不可兼得”的尴尬局面。它深入内核底层，不仅消除了传统旁路审计被绕过的风险，还通过高内聚的 K8s 元数据集成，为 SRE 和安全人员提供了一把洞察集群底层的“显微镜”。有了这套平台，企业不仅能够轻松满足等保合规要求，更能构建起稳固的云原生零信任运行时防御体系。

架构师TechRoad eBPFCilium云原生安全

评论点评