【Falco】Plugin 框架：container / k8smeta 与 syscall 主路径

前几篇把 syscall 路径走到规则与输出；本篇回答：plugin 插在哪一层、与驱动主路径如何分工，以及元数据空时规则为何「像没写」。核心误区是把 container.* / k8s.* 字段当成驱动保证的内核事实——在 0.44.1 叙事里，它们大量来自 plugin 富化，失败域独立于 modern_ebpf ∥ kmod。

另一类误区是「装了插件等于规则更强」：插件只提供字段或事件源，威胁语义仍由 YAML 条件决定。插件未加载时，依赖其字段的规则不会报「缺插件」，而会以条件为假的形式消失——这与第 6 篇失败表象直接咬合。排障若只看规则 diff、不看 load_plugins 与运行时套接字，会在错误层循环。

不写第三方 plugin 百科，不把未钉版本的插件行为写成 0.44.1 事实。读完应能画出 syscall 路径与 plugin 路径的合流图，并解释为何元数据空洞会让「已加载规则」静默。

本篇在系列中的位置

篇目	核心内容
第 8 篇 · 输出面	sink 与 gRPC 删除门
第 9 篇 · Plugin 框架	container / k8smeta、字段合流、元数据空
第 10 篇 · 部署与 driver.kind	Helm、auto、least-privileged
系列目录	关键问题、阅读路径、全部价值点

版本锚定：Falco 0.44.1。plugin 配置面见 tag falco.yaml 的 load_plugins / plugins。与 0.44 发行追踪对齐的参考工件：container 插件 0.7.1、k8smeta 0.4.1（Helm chart / 发布 tracking 常见 pin）。开写或升版时仍须核对 falcosecurity/plugins 发布说明与当前 chart pluginRef，不以本文数字替代现场核对。

一、plugin 框架角色

官方 Plugins 文档把插件定义为符合公开 API 的共享库，可：

• 增加新事件源（供规则过滤）；
• 增加新可提取字段；
• 解析数据流中的事件；
• 向数据流异步注入事件。

对 Falco 守护进程而言：plugins 描述可加载库与 init_config；load_plugins 列出实际启用的名字（默认常为 []，显式开启）。事件源类插件与 syscall 源可并存；extractor 类插件则把字段并进既有求值面。只改 plugins 块却忘记写入 load_plugins，是「配置了但没加载」的常见疏漏。

框架解决的是扩展点，不是第二套规则语言。规则仍是第 6–7 篇的 YAML；插件决定某些字段有没有值、某些事件从哪来。相对「把所有逻辑塞进驱动」，plugin 让容器元数据与云审计等演进不必每次 bump 驱动 API/Schema——这是工程上的分叉收益，也带来「主路径健康、插件空洞」的新失败模式。

二、container / k8smeta（兼容 0.44.1）

二者常被一起提起，但依赖不同：container 依赖节点上可见的运行时接口；k8smeta 依赖集群内部署的 metacollector 与网络可达性。只开其一、却写依赖另一字段类的规则，会得到「半套富化」——部分告警有 namespace、部分没有，看起来像随机误报/漏报。

k8saudit 是审计日志事件源插件，与「给 syscall 告警贴 pod 名」不是同一条需求——tag 注释已写明二者勿混。本篇不展开 k8saudit 规则库。若目标只是规则里写 k8s.pod.name，应先核对 container 插件与运行时套接字，而不是默认去部署一套审计 webhook。

版本策略：正文承认上述 pin 来自 0.44 发布追踪与 chart；现场以 plugins 仓库 release 与所部署 chart values 为准。第三方或自建插件不在本系列保证范围。plugin ABI 与 Falco 用户态错配时，失败往往在启动加载阶段，而不是「偶发无告警」——那更像元数据空，见第四节。升 chart 时若只动 image.tag 而忘记同步 pluginRef，等于人为制造混部。

三、与 libsinsp 字段合流

flowchart LR
  subgraph syscall_path ["syscall path"]
    drv["modern_ebpf or kmod"] --> scap["libscap"]
    scap --> sinsp["libsinsp state"]
  end
  subgraph plugin_path ["plugin path"]
    rt["runtime or metacollector"] --> plug["container / k8smeta plugin"]
    plug --> fields["extra fields"]
  end
  sinsp --> merge["field table for rules"]
  fields --> merge
  merge --> eng["rule engine"]

图：syscall 主路径与 plugin 富化路径在规则求值前合流（英文节点）。

驱动路径提供 syscall 上下文；libsinsp 维护线程/FD/进程树（第 4 篇）。container / k8smeta 在用户态把镜像名、pod、命名空间等写入同一字段表。规则条件不区分「字段来自驱动还是插件」——只看见有值或为空。这种透明合流提高了规则可移植性，也让字段空洞更难从条件文本本身读出来。

因此「集群内规则不命中、单机裸进程命中」优先怀疑合流侧元数据，而不是先改 evt.type。对照 Tetragon 内核 exec_id 血缘：Falco 此处仍是用户态拼装；plugin 延迟或失败不会回滚已捕获的 syscall 事件，只会让依赖元数据的规则变瞎。

四、元数据空时的失败表象

与第 6 篇「条件永远假」同构：表达式合法，左侧空。证据应包括插件启用列表与元数据源健康，而不是只 diff 规则 YAML。建议的静态核对顺序：load_plugins → 库文件是否存在于容器 → 运行时套接字/metacollector 网络策略 → 规则是否依赖仅在 k8smeta 启用后才存在的字段类。

无环境不伪造「container.id 为空」的日志行；语义上这类字段缺失即足以让依赖它们的规则静默。若必须在无集群时验证规则逻辑，应使用不依赖容器字段的最小条件，或明确标注「该规则仅在 plugin 富化成功后有效」。

五、不写第三方 plugin 百科

本系列对 plugin 的承诺止于：

• 框架在流水线中的位置；
• 与 0.44.1 强相关的 container / k8smeta 分工与空元数据失败模式；
• 指向 plugins 仓库与 chart pin 的核对义务。

不写：每个注册插件的配置菜谱、未核对 ABI 的「推荐插件列表」、用插件营销话术替代五轴排障。事件源类插件（云审计、业务日志等）若引入，须单独做版本门与规则源测试，不能假定与 syscall 主路径同 SLA。一条云审计规则静默，不应自动推导「节点上的 modern_ebpf 坏了」。也不写 k8saudit 全书、未现场核对的插件行为冒充 0.44.1 事实、以及伪造的字段为空日志样本；驱动 auto 见第 10 篇。

开放问题（研究台账 06–09）：plugin 富化与 syscall 主路径的一致性 SLO——元数据延迟或空洞是否应进入与 drop 同级的值班指标。选型与联合 runbook 留到第 14–16 篇。在 SLO 缺位前，最低工程要求是：把「container/k8smeta 字段填充率」或等价健康信号从「有则更好」提升为排障必查项。

参考资料

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

• Falco Plugins；Plugins Architecture Concepts
• Falco 0.44.1 falco.yaml：load_plugins、plugins（含 container 示例与 k8saudit 辨析注释）
• falcosecurity/plugins：container / k8smeta 说明与字段类
• Falco 0.44 发布 tracking / 0.44.1 changelog（container 0.7.1 bump）；Helm chart 中 k8smeta 0.4.1 pluginRef（部署时复核）

站内对照（A/B）

• 第 4 篇 · libsinsp；第 6 篇 · 规则语言；PLAN.md §九 · 09

学术 / 争论指针（A/B）

• 用户态富化 vs 内核血缘：对照 Tetragon 进程模型；检查窗口谱系见第 1、14 篇（Garfinkel NDSS 2003）

上一篇：输出面

下一篇：部署与 driver.kind