Falco 规则引擎的生态变化怎样影响运行时检测

Falco 的运行时检测正在从“加载一份默认规则文件”转向由引擎、驱动、规则 artifact、插件事件源、部署工具和告警消费端共同组成的生态。2026 年 9 月 21 日发布的 Falco 0.45.0，又把原始字节匹配、规则输出转义、驱动 API、容器插件和 Helm 部署之间的兼容关系推到了升级清单的前面。

官方地址：https://falco.org/

这次变化的重点不是“多了几条检测规则”，而是规则已经成为带有引擎、插件和发布边界的可组合资产。升级 Falco 时，必须同时检查规则内容、事件源、驱动、分发方式和下游输出解析。

从单一规则文件转向可组合生态

Falco 的核心仍然是对事件流应用条件并生成告警，但事件流不再只来自 syscall。官方文档把驱动、Falco 引擎、规则、插件和 falcoctl 分成了不同职责：驱动提供内核事件，插件可以提供新的事件源或字段，规则负责表达检测条件，falcoctl 负责安装和更新规则、插件等生态 artifact。

这里有三个容易混淆的边界：

• 事件采集边界：modern eBPF probe、kernel module 或插件事件源决定 Falco 能看到什么事件。
• 规则与扩展边界：规则文件、宏、列表和插件字段共同决定条件能否被编译与匹配。
• 运维与输出边界：falcoctl、Helm、ConfigMap 和下游消费者决定规则如何到达运行实例，以及告警怎样继续流转。

因此，规则文件不是孤立文本。一个规则可能依赖特定字段、事件源或插件版本；一个输出消费者也可能依赖 Falco 的转义格式。只更新其中一个组件，运行时检测的实际含义就可能发生变化。

Falco 0.45.0 把哪些兼容点推到台前

官方发布说明把 Falco 0.45.0 定义为包含破坏性变化的版本，升级前需要检查自定义规则、输出消费者和驱动。最值得关注的是下面四组变化。

原始字节匹配尤其容易被忽略。0.45.0 在规则条件中保留原始字节，允许使用 \xHH 表达单个字节；但正则运算仍然处理经过清洗的输入。也就是说，条件匹配和告警展示不是同一层语义：规则可以检查原始数据，输出则要保持可打印和可传输。

如果下游系统按旧格式拆字段，升级时应把“是否能收到告警”和“是否能正确解析告警”分成两个问题。前者属于 Falco 输出链路，后者属于消费者契约，不能只看 Falco 进程是否正常。

规则分发方式正在从文件复制转向 artifact 管理

官方文档说明，Falco 规则可以放在默认文件、本地规则文件和 /etc/falco/rules.d 目录中；也可以由 falcoctl 从 OCI artifact 下载和更新。Helm chart 默认会让 falcoctl 获取与 Falco 版本兼容的规则，并通过 follow 配置持续跟随更新。另一种选择是关闭运行时下载，固定使用镜像中自带的规则快照。

# 通过 Helm 明确选择规则 artifact，并让规则文件进入 Falco 的加载列表
helm install falco falcosecurity/falco \
  --set "falcoctl.config.artifact.install.refs={falco-rules:5}" \
  --set "falcoctl.config.artifact.follow.refs={falco-rules:5}" \
  --set "falco.rules_files={/etc/falco/falco_rules.yaml,/etc/falco/falco_rules.local.yaml,/etc/falco/rules.d}"

# 需要可重复发布时，关闭运行时 artifact 跟随，改由镜像或配置管理固定内容
helm install falco falcosecurity/falco \
  --set falcoctl.artifact.install.enabled=false \
  --set falcoctl.artifact.follow.enabled=false

这两种方式没有绝对优劣，差别在于更新责任落在哪里。自动跟随适合希望快速获得兼容规则和生态更新的团队，但需要把 artifact 版本、回滚策略和变更通知纳入发布流程；固定快照更容易复现，却要求团队主动安排规则更新。

如果只想加载自己维护的 ConfigMap 规则，官方做法是把 falco.rules_files 指向 /etc/falco/rules.d，并关闭默认 artifact 的安装和跟随。关键不在于选择哪一种，而在于不要同时让多个来源对同一规则文件负责，导致“线上到底加载了哪份规则”无法解释。

插件让规则引擎覆盖更多事件，但也增加了版本边界

插件的价值是把 CloudTrail 等外部事件源接入 Falco，或从事件中提取新的字段。规则中的 source 会把规则映射到对应事件源；Falco 会根据已加载插件的事件源选择性编译规则、宏和列表。这个机制意味着，插件不是旁路采集器，而是规则可用性的一部分。

# 只加载配置中声明的插件，避免未使用的事件源进入当前实例
plugins:
  - name: cloudtrail
    library_path: libcloudtrail.so
    init_config: ""
    open_params: ""
  - name: json
    library_path: libjson.so
    init_config: ""
    open_params: ""

# 中文注释：按实例用途选择真正加载的插件，名称必须与上面的声明一致
load_plugins: [cloudtrail, json]

官方还提供了 required_plugin_versions，用于在规则文件中记录兼容的插件版本。升级时，这个字段可以帮助团队把“规则语义变化”和“插件实现变化”放到同一张变更单上；如果规则文件没有声明插件版本，则不会自动进行插件兼容检查，不能把缺少报错理解成完全兼容。

面向生产的升级检查清单

把这次生态变化落到运行时检测，建议按下面五个边界安排回归，而不是只执行一次 Helm upgrade。

1. 驱动：确认 Falco 0.45.0 使用的驱动 API 与实际 driver 匹配，关注 modern eBPF 的额外辅助 map 内存，以及内核是否支持所需的原子操作。
2. 规则：逐项查看自定义规则是否依赖 UTF-8 清洗、特殊字节、通配符匹配或旧的规则成熟度；不要只以“规则文件能加载”作为成功标准。
3. 插件：记录插件名称、版本、事件源和字段，确认 required_plugin_versions 是否覆盖关键规则；容器插件的运行时连接与元数据恢复也要单独关注。
4. 部署：明确规则来自镜像、falcoctl OCI artifact 还是 ConfigMap，记录 install/follow 是否开启，保证回滚时能恢复同一份规则和插件组合。
5. 输出消费：让日志解析、SIEM、告警路由和自动化响应分别检查控制字符、非法 UTF-8、JSON 字段和告警级别映射，避免检测命中了但消费端丢失语义。

这份清单对应 Falco Roadmap 的方向：项目正在推进更清晰的特性采用与弃用策略、规则语法整理、现代 eBPF 默认化、供应链安全和更深入的插件框架能力。对使用者而言，长期收益是边界更清楚；短期成本是升级不能只盯着内核探针或规则 YAML 的单点变化。

常见问题

Falco 规则是不是越新越好？

不一定。稳定、incubating 和 sandbox 规则的定位不同，规则成熟度也不等同于你的环境一定低噪。应先明确规则来源、适用事件源和例外配置，再决定是否启用。

关闭 falcoctl 的自动跟随会不会失去所有更新？

会失去运行时自动获取规则 artifact 的路径，但可以通过镜像、配置管理或固定版本的发布流程更新规则。关闭跟随换来的是更强的可复现性，不是永久不维护。

为什么 Falco 进程正常，告警系统却解析失败？

Falco 0.45.0 调整了输出转义，规则匹配的原始字节与最终展示字符串也可能不同。应分别检查 Falco 输出、传输层和消费者解析器，不要只看探针是否加载成功。

结语

Falco 规则引擎的生态变化，本质是运行时检测从“规则文本”走向“兼容资产”。升级前把驱动、规则、插件、artifact 分发和输出消费放在同一张依赖图中，才能判断一次变更究竟改变了采集范围、匹配语义，还是告警呈现方式。

参考资料

• Falco 0.45.0 官方发布说明
• Falco Rules 官方文档
• Default and Local Rules Files 官方文档
• How Falco Uses Plugins 官方文档
• Falco Roadmap 官方文档