【Tetragon / eBPF】选型收束：排除树、开放问题与系列边界关闭
内容提要
本文是Tetragon运行时安全系列终章，通过排除树机制收束选型判断。核心观点：先排除再选择，依据可证伪的机制问题而非场景。明确何时不该用Tetragon（如无BTF、编制不足、仅需CNP+Hubble），回收Cilium 16的悬空指针，列出TOCTOU边界、导出完备性等开放问题，并给出ADR友好建议：排除树进ADR，五轴进发布门禁，禁止以“安全套件已安装”续跑。
延伸解读
排除树的价值：把选型从“看场景”变成“可证伪”
本文的核心贡献是提出一套基于机制判据的排除树，每个节点都是一个可证伪的问题，例如“是否需要进程或系统调用上下文”“内核是否有 BTF”。这种方法的优势在于，它迫使决策者基于具体的技术约束而非模糊的“场景”或品牌偏好来做选择。例如，如果需求仅停留在 CNP+Hubble 层面，或内核缺少 BTF，那么 Tetragon 就被明确排除，避免了盲目部署。这种结构化的决策工具尤其适合写入 ADR，为团队提供可审计、可重跑的选型依据。
明确“何时不该用”比“何时该用”更重要
文章列出了多个“否证条件”，即只要满足任一条件，就不应运行 Tetragon。这些条件包括：运维团队无法掌握五轴（血缘、hook、加载键、sink、Override）、需求仅需 CNP+Hubble、Falco 规则库已足够且不需要内联 Override、内核无 BTF 等。这种“先排除”的思路有助于避免将 Tetragon 作为“安全套件”盲目安装，从而减少运维负担和潜在风险。同时，文章强调沉没成本（如发行版默认安装）不应成为继续使用的理由，应重新评估。
开放问题提醒：版本锚定与能力边界
文章特别指出，v1.7.0 之后的上游进展（如 spec.nodeSelector 和 domain sharding）不应被误认为当前版本的能力。这提醒读者在阅读文档或进行选型时，必须严格锚定版本，避免将未来功能当作现有能力。例如，v1.7.0 的加载键是 collectionKey{name, namespace}，而 domain sharding 是后续引入的，因此在排障时不能使用 tetra tracingpolicy domains 命令。这种版本敏感性对于生产环境的稳定性和排障准确性至关重要。
Q&A
Tetragon 选型排除树的核心判断逻辑是什么？
排除树的核心是先排除再选择，每个叶子节点对应一个可证伪的机制问题，而不是笼统的“看场景”。例如，如果不需要进程或系统调用上下文，则不需要 Tetragon；如果需要身份网络策略和 Hubble，则用 Cilium CNP 和 Hubble；如果需要进程上下文但内核没有 BTF，则不要运行 Tetragon；如果只需要 Falco 规则库且不需要内联 Override，则选择 Falco；如果合规目标是主机审计账本，则用 auditd；如果编制无法支撑五轴，则暂缓运行 Tetragon。
在什么情况下不应该使用 Tetragon？
以下任一情况都不应使用 Tetragon：编制撑不住五轴（无法区分无事件、撞名、导出缺口、Override 门闩）；需求仅停留在 CNP + Hubble；Falco 规则库足够且不需要内联 Override；内核没有 BTF 且无法提供可用 BTF 文件；把“安装了 Tetragon”当作已具备强制执行能力（未核 Override config、monitor/enforce 模式、Runtime Hooks）。
Tetragon 的 Override 和 SIGKILL 有什么区别？
Override 可以让内核操作不执行（例如阻止系统调用），而 SIGKILL 是杀死进程但无法撤销已经发生的副作用。例如，SIGKILL 后 write() 可能已经落盘，而 Override 可以阻止 write() 执行。Override 需要 CONFIG_BPF_KPROBE_OVERRIDE 配置，并且存在 TOCTOU 边界；SIGKILL 语义更简单但副作用不可逆。
Tetragon 系列中提到的五轴是什么？
五轴指的是进程血缘、Sensor/Hook、策略加载（collectionKey）、事件导出（sink）和 Override（强制执行）。这五个方面是运维 Tetragon 时必须掌握的关键维度，用于排障和判断是否适合使用 Tetragon。
Tetragon v1.7.0 之后有哪些开放问题？
开放问题包括：TOCTOU 的可接受边界（何种 TOCTOU 被 ADR 接受）；导出完备性（JSON 与 gRPC 所见事件能否对齐）；与 Cilium identity 的联合 runbook（故障时先查 Hubble 还是 process_exec）；以及 v1.7.0 之后的 spec.nodeSelector 和 domain sharding 功能（这些是后续版本才有的，不能当作 v1.7.0 的能力）。
如何将 Tetragon 选型决策写入 ADR？
ADR 应包含排除树卡在哪一叶的机制判据，并附否证条件。示例句：“若平台不再维护 Tetragon 五轴值班，或不需要进程/syscall 上下文，则 Tetragon 叶必须重跑排除树，禁止以‘安全套件已安装’续跑。” 同时，若选择 Tetragon，需将五轴进发布门禁、集合键所有权进变更单、Override config 与 TOCTOU 接受度进威胁模型、Runtime Hooks 进身份强制执行检查、JSON sink 与 gRPC 分叉进值班。
Tetragon 与 Cilium 的关系是什么？
Tetragon 是 Cilium 生态中的运行时安全组件，Cilium 16 终章将 Tetragon 作为续作入口，本系列回收了该指针，明确了分工：Cilium 负责 identity/policy map/Hubble deny，Tetragon 负责 exec_id/TracingPolicy/Override/导出分叉。两者互补，但不要用 Hubble 回答进程问题。
