Tetragon / eBPF 运行时安全：从进程血缘到 TracingPolicy
内容提要
本文介绍Tetragon v1.7.0运行时安全系列文章，聚焦eBPF安全事件处理路径。内容涵盖进程模型、Sensor/Hook、TracingPolicy选择器、事件导出与强制执行机制，并对比Falco、auditd及Cilium CNP/Hubble。文章提供16篇阅读路线，帮助安全工程师理解延迟、丢失与误阻断问题，并指导选型决策。
延伸解读
版本锚定与能力边界
文章明确将机制结论钉在 Tetragon v1.7.0 源码 tag 上，并指出 spec.nodeSelector 与 domain sharding 晚于该版本，不作为系列能力。这提醒读者在参考时需注意版本差异，避免将新特性误认为旧版本能力，也提示在选型或排障时应以实际部署版本为准。
事件丢失与导出不一致的根源
文章提出多个关键问题：事件从 hook 到导出可能在哪层丢失，为何 TracingPolicy 已过滤但 tetra 仍可能看到“不该出现”的事件，以及导出与 gRPC 不一致的原因。这些问题指向内核过滤、事件导出路径和用户态处理之间的复杂交互，提示安全工程师在排查时需关注过滤逻辑与导出配置的匹配。
强制执行机制的局限
文章强调 Override 与 SIGKILL 的保证不同：Override 使函数不执行并返回错误，而 SIGKILL 终止进程但不保证当前 syscall 无副作用，并提及 TOCTOU 边界。这提醒读者在依赖强制执行时需理解其能力边界，避免高估阻断效果，尤其在需要严格副作用控制的场景。
选型决策的排除树
文章提供与 Falco、auditd、Cilium CNP/Hubble 的对照，并给出“何时不该上 Tetragon”的视角。这有助于架构师根据自身需求（如纯网络策略、主机审计或运行时安全）进行路径选型，避免盲目采用，同时强调需显式排除树，不重写 CNP/Hubble。
Q&A
Tetragon v1.7.0 中 exec_id 是如何生成的？
exec_id 由 node:ktime:pid 生成，用于唯一标识进程执行事件，并用于构建进程血缘关系。
Tetragon 的 TracingPolicy 选择器在内核中如何过滤事件？
TracingPolicy 选择器定义在内核中匹配事件的条件，只有满足选择器的事件才会被进一步处理或导出，从而减少不必要的开销。
Override 和 SIGKILL 在 Tetragon 强制执行中有什么区别？
Override 使被 hook 的函数不执行并返回 argError，从而阻止操作；SIGKILL 直接终止进程，但不保证当前系统调用无副作用。
为什么 TracingPolicy 已经过滤了事件，但 tetra 仍可能看到不该出现的事件？
可能因为导出过滤与内核过滤不一致，或者事件在导出前未被完全过滤，导致 tetra 显示的事件与策略预期不符。
Tetragon 与 Falco 在运行时安全方面有何主要区别？
Tetragon 基于 eBPF 提供更细粒度的内核级事件和强制执行，而 Falco 更侧重于规则检测和告警，两者在事件处理路径和策略执行上有所不同。
在什么情况下不应该使用 Tetragon？
当仅需要网络策略（如 Cilium CNP/Hubble）或主机审计（auditd）时，可能不需要 Tetragon；或者当内核策略的税（性能开销）不值得付出时。
Tetragon 的进程模型如何利用 exec_id 和血缘关系？
exec_id 唯一标识进程执行，血缘关系通过 exec_id 关联父子进程，结合 K8s 富化信息，提供比 /proc 重建更准确的进程树。
Tetragon 支持哪些 hook 类型？
支持 kprobe/kretprobe、tracepoint/rawtp、uprobe/USDT、LSM 和 fentry（v1.7.0）。
