【Falco】选型收束与开放问题：排除树与系列边界关闭

前 15 篇把 Falco 运行时检测拆到可归因精度：双引擎、libscap 协商、libsinsp 富化、规则与输出、排障五轴，并对照了 Tetragon、auditd、seccomp，划清了响应生态边界。选型若再写成「各有优劣看场景」，等于把机制丢掉。

本文是终章：用机制排除树收束判断，回收 Tetragon 16 与 Envoy Gateway 16 指向的 Falco 叶，写明何时不该跑 Falco，列出仍开放的问题，并以 ADR 可粘贴的语言关闭「Falco 运行时检测内核」续作边界。不做跨方案延迟或 CPU 排行榜。

本篇在系列中的位置

篇目	核心内容
第 15 篇 · 响应与生态边界	下游接到哪
第 16 篇 · 选型收束（终章）	排除树、开放问题、边界关闭
系列目录	全部篇目

版本锚定：Falco 0.44.1（源码 tag 0.44.1，2026-06-11）；驱动 10.2.0+driver。legacy eBPF / gVisor / gRPC output 已删，不得写成当前能力。Tetragon 站内钉 v1.7.0；Envoy Gateway 钉 v1.9.0。产品对照见 observability/15；强制执行见 tetragon/；南北向见 envoy-gateway/。

一、机制排除树

排除树每一叶必须回答一个可证伪的机制问题，而不是「看场景」。

flowchart TD
  syscall{"Need process or syscall\ncontext beyond L3/L4?"}
  syscall -->|"No"| net{"Need identity-centric\nNetworkPolicy plus Hubble?"}
  net -->|"Yes"| cnp["Cilium CNP and Hubble\nno Falco required"]
  net -->|"No"| other["Out of runtime-detection scope"]
  syscall -->|"Yes"| inline{"Need inline Override\nof this operation?"}
  inline -->|"Yes"| tet["Tetragon path\nsee tetragon/16"]
  inline -->|"No"| audit{"Host audit ledger\nis the compliance target?"}
  audit -->|"Yes"| auditd["auditd path"]
  audit -->|"No"| rules{"Falco rules library\nand response process enough?"}
  rules -->|"No"| tetObs["Tetragon observe\nor rethink requirement"]
  rules -->|"Yes"| staff{"Can staff operate\nFalco five axes?"}
  staff -->|"No"| defer["Do not run Falco yet"]
  staff -->|"Yes"| drivers{"modern_ebpf or kmod\nreachable on nodes?"}
  drivers -->|"No"| nodrv["Do not run Falco"]
  drivers -->|"Yes"| falco["Falco 0.44.1 path"]

甜区：自管 Kubernetes，已有或愿意维护规则仓库与告警下游，不要求 inline Override，值班能用第 13 篇五轴说话，Driver 行与 10.2.0+driver 成对可核对，auto 回退若启用则对值班可见。

苦区：无人能区分「无原始事件」与「有事件无告警」；把 TracingPolicy 改写成规则文件却仍期望 Override；用已删的 gRPC output 接下游；无环境却用 CPU% 海报在 Falco 与 Tetragon 之间站队。

何时不该跑 Falco（否证条件）

下列任一成立，排除树上 Falco 叶判负（可写进 ADR）：

1. 编制撑不住五轴——不能用第 13 篇口令区分错引擎、协商失败、富化字段空、规则未命中、sink/丢事件。
   
2. 需求是 inline Override / Signal——用户态规则主路径不够；走 Tetragon 16。
   
3. 合规目标就是主机 audit 账本——不要用规则命中冒充 audit 留存。
   
4. 节点无法加载 modern_ebpf 且无法部署可用 kmod——没有采集面。
   
5. 把「装了 Falco」当成已具备自动遏制——未划清第 15 篇响应边界，未核 sink 仍存在。
   
6. 仅因 CVE-2022-26316 历史窗口而「弃用令」式决策——该 CVE 影响 Falco < 0.31.1；对 0.44.1 不是充分弃用条件（第 14 篇）。真正否证应来自上表机制判据，而不是口号。

否证触发后应重跑排除树。沉没成本不是机制判据：发行版默认装上、POC 转正、安全套餐捆绑，都要把现状当假设再走一遍上表。迁出税可以写进 ADR，但不能改写「编制读不懂五轴」或「其实需要 Override」这些事实。

seccomp 仍是容器基线（第 14 篇），与本叶正交：排除树判负 Falco，并不等于关掉 seccomp profile。

二、回收 Tetragon 16 与 Envoy Gateway 16 的 Falco 叶

Tetragon 16 排除树把「Falco 规则库已够且不要 Override」标为独立路径，并曾以「续作入口 / 规划已锁定」指向本系列。Envoy Gateway 16 同样挂上 Falco 检测内核入口、声明本系列不抢运行时检测。两条指针在姊妹终章交付时是悬空的机制叶：读者知道「还有用户态规则那一层」，但不知道双引擎如何分列、API/Schema 错配长什么样、相对 auditd/seccomp 如何排除、响应接到哪为止。

本系列交付后，该叶的机制内容如下——三边终章不再悬空：

给读完三边的人一句分工口令：

• 「identity / policy map / Hubble deny」→ cilium/
  
• 「该不该上 Tetragon / Override」→ Tetragon 16
  
• 「Accepted / XdsIR / 南北向」→ Envoy Gateway 16
  
• 「Driver / API·Schema / 规则已加载无告警」→ 本系列 13
  
• 「该不该上 Falco」→ 本篇排除树

Tetragon / EG 终章承诺的 Falco 续作指针，到此关闭悬空状态。不是「永远不再写检测」，而是：同一句「去看 Falco」不应再没有可核对篇章。

姊妹终章侧已改为指向本系列 index 与本篇排除树（不再写「规划已锁定」悬空语）。读者若仍只看到产品勾选文，应再进 第 1 篇 建立五轴，再回本篇做选型。

三、系列级开放问题（可证伪）

关闭条件必须是测量或正式文档/源码变更，不是路线图幻灯片。

3.1 auto 回退的可观测性

问题：driver.kind=auto 静默换引擎时，值班能否在不读节点日志全文的情况下证明「当前 Driver 行」与预期一致？
为何重要：轴 1 分列证据包；错引擎会导致按 modern_ebpf 能力集排 kmod 权限。
检验：异构节点上强制观察回退，核对状态/指标是否一等公民。
现状：auto 是运维门（第 10 篇）；是否升为一等 status 仍开放。

3.2 plugin 与 syscall 主路径的一致性 SLO

问题：container / k8smeta 元数据空时，带 plugin 字段的规则漏报，能否写成可验收的一致性目标？
为何重要：轴 3 与轴 4 易被误判成「规则仓库坏了」。
检验：固定规则集，对比「仅 syscall 字段」与「依赖 plugin 字段」在 plugin 故障注入下的命中差。
现状：失败表象已知（第 9、13 篇）；SLO 数字本系列不编造。

3.3 与 Tetragon / Cilium 的联合 runbook

问题：故障时先查 Hubble verdict、process_exec，还是 Falco 五轴？identity、exec_id 与 Falco 告警如何在同一张工单引用？
为何重要：三边都可以「看起来像安全事件」；轴用错会改错层。
检验：合成「CNP deny + 容器内 connect」「Falco 命中但无 Override」「Tetragon Override 挡住」——值班是否落到正确系列。
约束：本系列不裁决安装顺序；两边终章的联合 runbook 项保持开放，不要互相冒充关闭。

3.4 BPF iterators 默认策略

问题：0.44.0 引入 iterators 辅助 drop recovery；0.44.1 可禁用（容器可用性）。生产默认开还是关，应由谁在 ADR 里钉死？
为何重要：轴 5 丢事件归因与容器运行时兼容性冲突。
检验：声明默认策略，并在升级检查单核开关与 drop 指标。
现状：可关门已钉；默认叙事因环境而异，保持开放。

写给后续维护者：升 Falco 小版本时，先核这四项是否被官方文档/源码改变默认语义，再更新本篇「开放/已关闭」表，而不是重写排除树的问题顺序。 live 文档出现、tag 未包含的能力，保持开放项，不悄悄写进甜区。

四、显式关闭：本系列边界

给读完本系列的人三条收束（ADR 友好）

1. 排除树进 ADR：写清卡在哪一叶机制判据；附否证条件（编制减员、需要 Override、退回 auditd、驱动不可达、仅因历史 CVE 口号弃用）。示例句：
   「若平台不再维护 Falco 五轴值班，或需要 inline Override，则 Falco 叶必须重跑排除树，禁止以『运行时检测已安装』续跑。」
2. 若选了 Falco：第 13 篇五轴进发布门禁；第 2/10 篇 Driver 行与 auto 可见性进变更单；第 3/12 篇 API/Schema 成对升级进检查单；第 8/15 篇 sink 白名单与响应边界进值班——缺一项降级为试验集群。
   
3. 若没选：用第 14 篇机制表做代际复盘；禁止无口径 CPU 截图重开争论。需要 Override 时回 Tetragon 终章；需要南北向时回 EG 终章；需要产品勾选时回 observability/15。

终章立场：Falco 值得写成检测内核系列，是因为失败可命名——错引擎、协商失败、富化字段空、异常过宽、已删 gRPC sink、丢事件被当成无威胁。选型若离开这些名字，讨论退回安装量与品牌口号。记住一个动作：先排除，再打开规则仓库，再打开下游自动化——排除自带否证，规则自带富化依赖，自动化自带第 15 篇边界。

回到系列开头的缺口：Tetragon 16 与对照文留下的「Falco 叶」现已有可核对篇章。若读完仍只能复述功能清单，说明阅读停在目录；若能在故障里说出「这是轴 2 Schema 错配」或「这是轴 5 背压」，机制文才算交货。

对平台团队的务实建议：先用第 13 篇在试验节点跑通一次真实或演练故障（至少覆盖「无原始事件」与「命中了下游无」），再决定是否把 Falco 定为默认检测路径。若演练里卡在「读不懂五轴」，优先补第 1、2、3、8 篇门禁与编制，而不是先堆规则仓库。排除树的正确用法是缩短错误迁移，而不是证明某品牌永远正确。

若读者时间只够两篇：读 01 全景 建立缺口意识，再读本篇排除树；然后按自己的主轴跳进 02/06/13 之一。完整通读的收益是「症状能落格」；跳读的风险是把已删 gRPC sink 当成当前接线，或把历史 CVE 写成弃用令。

给维护者：补丁级更新应改版本钉与开放问题进展，而不是重写「先排除再选」的顺序。若 3.x 随新 tag 或测量关闭，在本篇追加「已关闭项」并链到复盘，避免后人把 auto 一等 status 写回「从未存在」。

参考资料

规范 / 官方文档 / 源码（A）

• Falco 0.44.1 / 0.44.0 Release Notes 与 Changelog；drivers 10.2.0+driver
• 本系列 PLAN.md §六、§八；第 1 篇 五轴
• Tetragon v1.7.0 终章；Envoy Gateway v1.9.0 终章

工业反例（B）

• GHSA-6v9j-2vm2-ghf7 / CVE-2022-26316（Falco < 0.31.1；非 0.44.1 弃用令）

站内对照

• 系列目录
• Tetragon 16 · Falco 原指针
• Envoy Gateway 16 · Falco 原指针
• 第 14 篇 · 对照
• 第 15 篇 · 生态边界

实验台账

• 本篇无跨方案 benchmark；选型依据为机制排除。开放问题关闭依赖测量或上游文档，不在此伪造时间线。

上一篇：响应与生态边界

下一篇：系列目录