【Falco】运行时检测全景：缺口、五轴坐标系与 16 篇路线
内容提要
本文介绍Falco 0.44.1运行时安全检测系列，聚焦modern_ebpf与kmod双引擎、libscap/libsinsp机制及规则引擎。文章定义五条排障坐标系：驱动加载、协商、状态富化、规则引擎、输出丢事件，并指出0.44已删除legacy eBPF和gRPC输出。核心是帮助识别检测事件在驱动、协商、富化或规则层的具体失败位置，而非简单安装指南。
延伸解读
五轴排障：先定位失败层，再动手改配置
文章提出五条排障坐标系，将检测事件从驱动加载到输出丢事件的全过程拆分为可独立核对的阶段。排障时先判断问题落在哪一轴，再深入对应模块，而不是一上来就改规则或重装 DaemonSet。例如，DaemonSet 就绪但 Driver 行与预期不符，优先查驱动加载轴；升级后无任何 syscall 事件，优先查 libscap 协商轴。这种分层方法有助于避免误判，提高排障效率。
0.44 版本破坏性变更：升级前必查兼容性
Falco 0.44 删除了 legacy eBPF、gVisor engine 和 gRPC output，且驱动 API/Schema 大版本升级，0.43 驱动与 0.44 用户态不兼容，必须升级到 10.2.0+driver。升级前需核对驱动版本、输出配置，避免旧 runbook 中的 gRPC sink 失效。auto 回退机制可能静默切换引擎，导致排障时证据包指向错误引擎，需关注其可观测性。
用户态规则引擎的局限：富化与输出是独立失败域
Falco 的采集在驱动层，判定在用户态 libsinsp，因此必须区分“无原始事件”和“有事件无告警”。规则条件引用的字段可能因富化失败而为空，导致规则静默不命中；输出 sink 背压或已删除的 gRPC 输出也可能让命中事件在下游消失。排障时不能将 SIEM 空窗直接归因于“没有攻击”，而应检查富化字段和输出链路。
Q&A
Falco 0.44.1 支持哪两种驱动引擎？
Falco 0.44.1 仅支持 modern_ebpf 和 kmod 两种驱动引擎，legacy eBPF 已被删除。
Falco 0.44 相比 0.43 在驱动方面有什么重大变化？
Falco 0.44 对驱动 API 和 Schema 进行了大版本升级，导致 0.43 的驱动与 0.44 的用户态不兼容，必须升级到 10.2.0+driver。
Falco 0.44.1 中 driver.kind=auto 的作用是什么？
driver.kind=auto 是 falcoctl 或 Helm 的运维选择器，会先尝试加载 modern_ebpf，如果失败则回退到 kmod。它不是第三条内核路径。
Falco 0.44.1 中 gRPC 输出是否仍然可用？
不可用。Falco 0.44.0 已删除 gRPC output，下游不能再连接旧的 gRPC sink。
Falco 检测事件从捕获到告警要经过哪些主要阶段？
主要经过五个阶段：驱动加载（modern_ebpf 或 kmod）、libscap 协商（API/Schema）、libsinsp 状态富化、规则引擎求值、输出与丢事件处理。
Falco 中 libscap 和 libsinsp 的分工是什么？
libscap 负责从驱动读取事件并协商 API/Schema，libsinsp 负责维护机器状态、富化事件并执行规则过滤和输出。
Falco 0.44.1 中 BPF iterators 的作用是什么？
BPF iterators 在 0.44.0 引入，用于辅助丢事件恢复（drop recovery），在 0.44.1 中可以在容器场景下禁用。
Falco 排障时如何快速定位问题所在层？
先判断问题属于哪条不变量：无原始事件可能涉及驱动或协商层；有事件但无告警可能涉及富化或规则层；命中但下游无输出可能涉及输出层。然后沿五轴下钻。
