Tetragon：用 eBPF 把内核事件变成可执行的 Kubernetes 安全策略

它解决什么问题：内核事件与工作负载身份之间的鸿沟

传统安全监控工具要么只提供日志，要么需要在内核外做代理，很难把一次 `execve` 调用和某个 Kubernetes Pod 的归属关系直接对应起来。Tetragon 的定位很明确：用 eBPF 在内核钩子处捕获安全相关事件，然后把这些事件与 Linux 和 Kubernetes 的元数据绑定，输出带上下文的记录。它面向的是需要实时了解进程执行、系统调用、文件访问和网络活动的平台工程师或安全工程师。在 Kubernetes 环境里，它理解 namespace、Pod 等身份，因此策略可以针对单个工作负载，而不是整台宿主机。这个能力让安全策略从“这台机器上发生了什么”细化为“这个 Pod 里发生了什么”。

核心机制：sensor 与事件流

Tetragon 通过 sensor 在内核关键位置挂载 eBPF 程序。sensor 是它观察内核的抽象层，每种 sensor 负责一类事件。默认情况下，进程生命周期 sensor 会生成 `process_exec` 和 `process_exit` 事件，这为完整追踪进程启动和退出提供了基线。对于更细粒度的场景，它支持 generic tracing，生成 `process_kprobe`、`process_tracepoint` 和 `process_uprobe` 事件。这些事件不是原始内核转储，而是经过处理后附加了 Linux 元数据（如用户 ID、可执行文件路径）和 Kubernetes 元数据（如命名空间、Pod 名）。数据流大致是：内核事件触发 eBPF 程序，程序收集上下文，用户态组件聚合并输出为结构化事件。文档没有详细说明事件传输路径，但基于仓库布局，事件最终会通过 Tetra CLI 或 API 暴露给用户。

TracingPolicy：把安全需求翻译成内核钩子

高级用法的核心是 TracingPolicy，它定义了你关心哪些内核事件以及如何响应。官方文档列举了多种用例，包括网络可观测、文件名访问、Linux 进程凭据监控和特权执行检测。TracingPolicy 的写法决定了 eBPF 程序挂载到哪些 kprobe 或 tracepoint，以及事件如何过滤和输出。这里有一个明显的权衡：默认的进程事件几乎零配置就能用，但任何自定义追踪都需要你理解内核符号和追踪点，这对不熟悉内核 API 的开发者是门槛。文档没有给出具体 TracingPolicy 的 YAML 示例，但概念页明确说明它是“generic tracing”的配置入口。如果你只想观察进程生命周期，可以跳过它；但想监控特定系统调用或文件路径，就必须投入时间学习它的语法。

安装与启动：两条路径，一个 CLI

官方文档提供了两条主要安装路径：Kubernetes 和 Linux（通过 Docker）。在 Kubernetes 上，你可以按照安装指南部署 Tetragon 到集群，它会以 DaemonSet 或类似方式运行，确保每个节点都有 eBPF sensor。在 Linux 上，Docker 方式适合快速体验，不需要完整集群。安装后需要单独安装 Tetra CLI，这是与 Tetragon 交互的命令行工具，用于查看事件、管理策略。文档没有给出具体的 `kubectl apply` 命令或 Docker run 参数，但强调“getting started guides”是入口。我的判断是，Tetragon 的部署复杂度主要取决于你的 Kubernetes 版本和内核支持，因为 eBPF 需要较新的内核特性。如果你已经运行 Cilium，Tetragon 的集成会自然一些，但这不是文档明确说的，只是基于同属 Cilium 项目的推断。

局限性与失败模式：不是万能的内核监控

Tetragon 的 eBPF 依赖意味着它无法在旧内核上运行，这是最直接的限制。文档没有列出最低内核版本，但 eBPF 的成熟度与内核版本强相关，所以你需要先验证自己的环境。另一个局限是事件类型覆盖范围：虽然它覆盖进程、系统调用、文件和网络，但“系统调用活动”并不等于所有系统调用，具体哪些钩子可用取决于 sensor 的实现。如果内核没有暴露你需要的 kprobe 点，TracingPolicy 就无能为力。此外，在 Kubernetes 环境中，事件与 Pod 身份的绑定依赖于 kubelet 和容器运行时的元数据，如果这些数据不完整或延迟，事件可能丢失身份信息。文档没有提及性能开销，但任何 eBPF 监控都有开销，高频率事件（如密集文件访问）可能产生大量数据，需要外部存储和处理。

替代方案：Falco 与 Cilium 的生态差异

与 Tetragon 最直接的对比是 Falco，后者同样是云原生运行时安全工具，也使用内核模块或 eBPF。Falco 的核心思路是规则引擎，用户编写条件规则（如“打开 /etc/shadow”），它匹配事件并发出告警。Tetragon 则更偏向策略驱动的强制，TracingPolicy 直接控制 eBPF 程序的行为，而不是事后过滤事件流。另一个区别是 Tetragon 是 Cilium 的原生组件，如果你已经使用 Cilium 做网络，那么网络可观测性可以复用同一套 eBPF 基础设施，而 Falco 是独立项目，需要单独部署和集成。Falco 的规则语法可能更接近传统安全工程师的思维，Tetragon 则要求你理解内核概念。两者没有绝对优劣，选择取决于你的团队是更熟悉 Kubernetes 和 eBPF，还是更熟悉传统的规则引擎。

维护与许可证：Apache-2.0 下的社区项目

Tetragon 以 Apache-2.0 许可证发布，这意味着你可以自由使用、修改和分发，甚至用于商业产品，但需要注意保留版权声明。仓库最近一次提交在 2026 年 8 月，版本 v1.7.1 刚刚发布，显示出活跃的维护节奏。v1.7.0 在 2026 年 4 月发布，v1.6.1 在 2026 年 3 月，大约每季度一个次要版本。这种节奏对采用者意味着你需要跟随升级，因为 eBPF 程序与内核版本绑定，新版本可能修复兼容性或增加 sensor。文档提供了贡献指南，并要求开发者签署 DCO（Developer Certificate of Origin），这保证了代码来源的合规性。社区渠道包括 Slack 和定期社区电话会议，对于遇到内核兼容问题的用户，这些是求助的第一站。升级成本没有直接说明，但考虑到 eBPF 的复杂性，建议在测试环境验证新版本后再上生产。

编辑结论

Tetragon 适合已经运行 Kubernetes 且需要内核级安全事件可见性的团队，尤其是那些希望用 Kubernetes 原生身份（命名空间、Pod）来定义安全策略的运维或安全工程师。它不适合仅需要传统主机入侵检测或对 eBPF 内核版本兼容性没有足够运维能力的团队。在采用之前，应先验证你的内核版本是否满足 eBPF 要求，并阅读 TracingPolicy 的语法文档，明确你需要的 kprobe、tracepoint 或 uprobe 事件是否都能被当前内核支持。Tetragon 的价值不在于替代现有安全工具，而在于把内核事件变成可编程的、与工作负载绑定的策略引擎，这一判断应当基于你的实际事件需求，而不是功能清单。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes