【Falco】规则加载与 falcoctl：默认集、远程与热加载边界

第 6 篇 假定规则已在引擎里；本篇回答规则文件如何进入进程，以及热更新边界停在哪。核心问题是：falco -L 看不到规则、看到了却与预期文件不一致、或磁盘已更新但进程未换规则——分别落在加载配置、falcoctl 分发，还是重载门。

规则轴因此拆成两段：第 6 篇管「引擎如何判真假」，本篇管「判真假的材料从哪来」。材料链路一旦断裂，后面所有条件调优都是空转。falcoctl 把 OCI 工件落到磁盘，并不自动等于 Falco 已编译进内存；Helm 打开 follow，也不自动等于 rules_files 指向了新路径。把这几步焊成一条「规则已更新」工单状态，是变更审计里的常见漏洞。

不写每个规则仓库的订阅菜谱，也不把 live 文档后版本能力写成 0.44.1。读完应能画出：包内快照 / 本地挂载 / falcoctl artifact → rules_files →（可选）watch_config_files 或 SIGHUP → 引擎，并指出每一跳的失败表象。

本篇在系列中的位置

篇目	核心内容
第 6 篇 · 规则语言与引擎	条件、优先级、异常
第 7 篇 · 规则加载与 falcoctl	默认集、本地/远程、热加载边界
第 8 篇 · 输出面	sink 白名单与 gRPC 删除门
系列目录	关键问题、阅读路径、全部价值点

版本锚定：Falco 0.44.1；随 0.44 发布说明中的 falcoctl 0.13.0、falco-rules 工件族。加载与监视语义以 tag 0.44.1 的 falco.yaml（rules_files、watch_config_files）及同版本主机安装文档为准。live /docs/ 仅作线索。无环境则不伪造 falcoctl artifact / falco -L 输出。

一、默认规则集

发行包与容器镜像携带一份官方规则快照（历史上常见路径含 /etc/falco/falco_rules.yaml）。tag falco.yaml 写明：该文件随软件版本覆盖；falco_rules.local.yaml 仅在不存在时创建，用于本地覆盖而不被包更新冲掉。把自定义逻辑写进会被覆盖的默认文件，是升级后「规则消失」的经典自伤——本地覆盖应落在 .local、rules.d 或独立 artifact。

rules_files（Stable）列出要加载的文件或目录：文件直接读；目录内按字母序加载 .yml / .yaml（自 0.41 起仅这些扩展名）。加载顺序 = 覆盖与 first 匹配的优先级来源——后文件可 override；同事件类型下更重要的规则应排在更前（与第 6 篇 rule_matching 呼应）。目录字母序意味着 10-base.yaml 与 99-local.yaml 这类命名会变成事实上的优先级协议，应写进变更规范，而不是口头约定。

Helm / 包默认还常包含 rules.d 目录，供 customRules 或运维投放额外 YAML。默认集解决「开箱有一组可运行规则」；它不是安全基线认证——基线要靠你们自己的加载清单与变更审计。关闭 falcoctl 自动更新、冻结镜像内快照，与「跟随上游 falco-rules」是两种运维策略，混用时必须能回答：当前节点磁盘上的规则哈希来自哪一次安装。

0.44.0 发布说明提到随发行的 falco-rules 5.1.0 一类工件版本；规则集版本与 Falco 用户态版本独立演进，升级用户态时须核对规则工件的兼容声明，不能假定「chart 升了规则自动正确」。

二、本地与远程（falcoctl）

falcoctl 把规则当 OCI artifact 分发：index add 后 artifact install（例如文档示例中的 falco-rules:<tag>）。Helm 侧常见开关：falcoctl.artifact.install（启动时安装）与 falcoctl.artifact.follow（周期性跟随更新）。关掉二者则只用镜像内快照，适合隔离网络或冻结变更窗。follow 间隔、refs 列表属于 falcoctl 自身配置，与 falco.yaml 的 rules_files 是两条配置面——改错面时会出现「falcoctl 日志显示已拉取，Falco 仍读旧路径」的分裂。

关键边界：falcoctl 负责把文件放到磁盘；Falco 进程负责解析与求值。 follow 更新了文件之后，是否进入内存取决于下一节的热加载配置——二者不是同一个子系统。把「规则已更新」定义成 OCI digest 变了，却不去验证进程内规则集，会在审计上留下假阳性成功。

0.44 起 falcoctl 已去掉 legacy eBPF 驱动操作与 tls 子命令等破坏项；本篇只关心规则工件路径，驱动回退见第 10 篇。规则加载排障时也不要顺手改 driver.kind：那是轴 1，除非同时存在「无原始事件」证据。

三、加载失败表象

加载失败与第 6 篇的「条件永远假」证据包不同：前者是规则根本未进入引擎或版本错乱；后者是引擎内求值为假。排障口诀仍是先点名轴：加载属规则轴的「入口」，富化属轴 3。若启动日志已明确规则解析错误，却去调 http_output，是把轴 4 入口问题错判成轴 5。

无真实节点时，语义上可用配置核对 rules_files 列表与容器内挂载，而不是粘贴伪造的 -L 清单。能核对的静态项包括：ConfigMap/宿主机文件是否挂到配置声明的路径、只读根文件系统是否阻止 falcoctl 落盘、多容器 Pod 里规则是否只进了 sidecar 没进 falco 容器。

四、热加载边界（以 tag 文档为准）

tag 0.44.1 falco.yaml 中 watch_config_files: true（Stable）：监视配置与规则文件变更并自动 reload，以便在不停掉进程状态机的前提下应用更新。主机安装文档补充：若关闭该选项，可用 SIGHUP（示例：kill -1 $(pidof falco)）手动触发重载；也可直接 systemctl restart falco（代价是完整重启）。热加载的价值在于保留 libsinsp 状态表；完整重启会清空用户态进程/FD 上下文，短期内可能出现富化空洞——这又会反馈成第 6 篇的「条件假」。

本篇只承诺上述 tag 已写明的门。下列事项不以 live 文档臆造：

• 热加载是否覆盖某次 falcoctl follow 的全部竞态；
• 多线程架构落地后监视语义是否变更；
• 某发行版对 inotify / 挂载传播的特殊限制。

若运维手册需要更细的「改哪类键必须重启」，以源码 tag 0.44.1 配套文档与该次发布说明为准，不把后版本 blog 能力写回本系列。原子替换规则文件（写临时文件再 rename）通常比原地截断写入更不容易让监视器读到半份 YAML；具体文件系统行为以你们运行时实测为准，本文不编造 inotify 时序。

watch_config_files 监视的是 Falco 已配置要读的路径；falcoctl 把 artifact 落到未被 rules_files 引用的目录时，监视再灵敏也不会加载。改驱动引擎、plugin 二进制等是否算「热加载」——本篇不扩展；驱动见第 10 篇，plugin 见第 9 篇。

五、与 plugin 规则源的分工（指针）

本篇的「规则」指 YAML 规则文件进入 libsinsp 引擎。Plugin（container、k8smeta、以及事件源类插件）扩展的是字段与事件源，不是用另一套 YAML 方言替代 rules_files。把「安装了 container 插件」理解成「规则已加载」，会在排障记录里制造假进展。

• 缺 container.* / k8smeta.* 导致条件假 → 查 plugin 是否加载、元数据是否空，见第 9 篇。
• 规则文件本身未出现在引擎 → 留在本篇的 rules_files / falcoctl / 热加载链。
• 规则在、字段在、仍无下游 → 离开本篇，进第 8 篇输出轴。

开放问题：规则工件版本与 Falco 用户态、plugin ABI 的联合兼容矩阵是否应成为一等公民发布物——本系列在运维篇回指，这里只要求排障时分列「文件未加载」与「字段未富化」。在矩阵缺失时，最低限度是：每次升 0.44.x 记录 falco 版本、falco-rules 标签、container/k8smeta pin 三元组，而不是只记 chart appVersion。

本篇不写每个规则仓库的订阅菜谱、不伪造 falcoctl / -L 输出、不以 live 文档后版本热加载细节冒充 0.44.1；驱动 auto 与 plugin 字段深挖分别见第 10、9 篇。

参考资料

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

• Falco 0.44.1 falco.yaml：rules_files、watch_config_files
• Falco Default and Local Rules Files（falcoctl OCI 安装语义）
• 主机安装文档（DEB/RPM、tarball）中 Hot Reload / falcoctl artifact follow 说明（对齐 0.44.1 包）
• Falco 0.44.0 Release / blog：falcoctl 0.13.0、falco-rules 工件与破坏性变更列表

站内对照（A/B）

• 第 6 篇；第 9 篇；PLAN.md §九 · 07

上一篇：规则语言与引擎

下一篇：输出面