【Tetragon / eBPF】运行时安全全景：缺口、五轴坐标系与 16 篇路线
内容提要
本文介绍Tetragon v1.7.0的eBPF运行时安全机制，聚焦进程血缘、Sensor/Hook、策略加载、过滤分层和强制执行五轴坐标系，并阐述exec_id、execve_map等关键概念。文章旨在补齐Cilium数据面与可观测性之间的安全内核层，提供排障指南，并规划16篇系列文章路线，强调可核对锚点与失败模式分析。
延伸解读
五轴坐标系：排障先定位，再下钻
文章提出五轴坐标系（进程血缘、Sensor/Hook、策略加载、过滤分层、强制执行），每轴有可核对锚点与失败表象。排障口诀是“先点名轴，再下钻模块”，避免一上来就改TracingPolicy YAML或重装DaemonSet。例如，短命进程无父先查血缘轴，策略已apply但无事件先查hook轴，tetra与JSON不一致先查过滤分层轴。这种结构化方法有助于快速定位问题，而非盲目试错。
导出过滤的“陷阱”：JSON与gRPC可见集合不一致
v1.7.0中，JSON导出支持allow/deny过滤，但gRPC（tetra getevents）不受影响。因此，即使denylist已过滤事件，tetra仍可能显示。这是设计而非故障。若SIEM中无事件但tetra有，应优先检查过滤分层轴，而非怀疑策略未生效。理解这一机制差异，可避免误判和无效排障。
强制执行边界：Override与SIGKILL的保证不同
Override依赖CONFIG_BPF_KPROBE_OVERRIDE，可阻止函数执行并返回错误；而SIGKILL终止进程，但不保证当前syscall已完成（如write()可能已写入数据）。TOCTOU是系统调用拦截的经典问题，非Tetragon独有。因此，若策略匹配但文件已写入，应检查强制执行轴的保证边界，而非盲目扩大选择器范围。
版本锚定：避免用新功能解释旧版本
文章强调版本锚定：所有机制对齐Tetragon v1.7.0（tag v1.7.0），不引用live文档中的后版本能力（如spec.nodeSelector、domain sharding）。这提醒读者，在阅读文档或社区内容时，需注意版本差异，避免用新特性解释旧版本行为，导致误解和错误排障。
Q&A
Tetragon v1.7.0 中 exec_id 是如何生成的？
exec_id 由用户态 GetProcessID 将节点名、内核 ktime 和 PID 拼接为 node:ktime:pid，再进行标准 Base64 编码生成。
为什么 tetra getevents 仍能看到 denylist 已过滤的事件？
因为 v1.7.0 中 JSON 导出的 allow/deny 过滤不影响 gRPC 输出，tetra getevents 走 gRPC 通道，不受 JSON 导出过滤影响。
Tetragon 中 Override 和 Sigkill 在强制执行上有什么区别？
Override 让被 hook 的函数不执行并返回指定错误，依赖 CONFIG_BPF_KPROBE_OVERRIDE；Sigkill 终止进程，但不保证当前 syscall 不完成，例如 write() 可能已写入数据。
Tetragon 策略已 apply 但没有任何 kprobe 事件，可能是什么原因？
可能原因包括：hook 符号名写错、缺少 BTF、LSM 未启用、fentry 未被内核接受等，应优先检查 Sensor/Hook 轴。
Tetragon 中修改 CR 后不生效，可能是什么原因？
可能因为另一条加载路径（如 gRPC 或 --tracing-policy 文件）已占用同名集合，导致 CR 修改不生效，应检查策略加载轴。
Tetragon 的进程血缘轴中，短命进程看不到父进程是什么原因？
如果 fork 时父进程不在 execve_map 中，子进程不会进入进程图，这是失败路径，不是实现细节。
Tetragon 的过滤分层中，内核 selector 和 JSON 导出过滤有何不同？
内核 selector 在 hook 内决定事件是否产生，JSON 导出过滤在用户态决定是否写入日志，两者是不同集合，且 JSON 过滤不影响 gRPC。
Tetragon 的强制执行轴中，TOCTOU 是什么？
TOCTOU 是系统调用拦截类工具的经典失败模式，指检查与使用之间存在时间差，可能导致副作用已发生，Tetragon 也不例外。
