Falco 运行时安全规则更新怎样接入现有告警

Falco 规则更新接入现有告警，关键不是把整套告警平台重新搭一遍，而是把“规则怎么加载”和“事件怎么转发”分开管理。新规则放进独立文件，保留唯一的 rule 名称、priority、tags 与输出字段；Falco 继续生成 JSON，再通过既有的 HTTP 出口交给 Falcosidekick 或当前告警接收器。

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

先把规则更新和告警出口分开

Falco 默认配置会按 rules_files 指定的顺序加载规则文件，常见布局是默认规则、局部规则和 /etc/falco/rules.d 目录。这样做的好处是：规则更新只改变规则来源或加载内容，原来的 JSON、HTTP 或 Falcosidekick 出口仍保持稳定。

如果需要用 falcoctl 安装可更新的规则 artifact，可以把它看成“规则供应端”，而不是告警接收端。示例命令如下，具体版本要按当前 Falco 规则仓库提供的 artifact 选择：

# 添加 Falco 官方 falcoctl 索引，索引地址来自官方文档示例
falcoctl index add falcosecurity https://falcosecurity.github.io/falcoctl/index.yaml

# 安装指定规则 artifact；版本只是示例，生产环境应固定并记录实际版本
falcoctl artifact install falco-rules:3.2.0

直接维护配置文件时，先确认加载顺序：

# 先加载默认规则，再加载局部规则和独立自定义目录
rules_files:
  - /etc/falco/falco_rules.yaml
  - /etc/falco/falco_rules.local.yaml
  - /etc/falco/rules.d

如果要覆盖已有规则，必须让覆盖定义出现在原定义之后；如果只是新增检测项，则优先使用独立文件，避免升级默认规则时把本地改动揉成一份难以回滚的大文件。

写一个可以独立更新的运行时规则文件

规则文件应该围绕一个明确事件编写。下面用“容器内启动 shell”作为结构示例，重点不在这条规则是否适合每个环境，而在于把规则名、条件、输出和标签设计成下游容易识别的稳定字段。

- rule: Container shell started
  desc: 容器内启动交互式 shell 时生成运行时事件
  condition: spawned_process and container and proc.name in (sh, bash, ash)
  output: >-
    容器内启动 shell
    (user=%user.name shell=%proc.name command=%proc.cmdline
    namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [container, shell, runtime]

这里有四个需要与现有告警约定对齐的点：

• rule 名称要唯一且稳定，下游可以用它做聚合键；不要每次改规则描述就改名称。
• condition 只放能解释检测边界的条件，过宽会增加噪声，过窄又可能完全匹配不到。
• priority 要映射到团队已有严重级别，不能因为“新规则”就随意提高等级。
• output 中的字段应是下游已经能解析或愿意接入的字段，tags 则适合做路由、检索和报表过滤。

让新规则沿用结构化 JSON 告警

Falco 的 JSON 告警可以携带时间、规则名、严重级别、格式化输出、主机、标签和 output_fields。因此，已有系统如果已经按这些字段消费 Falco 事件，就没有必要为每条新规则另建一条告警管道。

# 让 Falco 以结构化 JSON 调用现有的 Falcosidekick HTTP 入口
json_output: true
json_include_output_property: true
http_output:
  enabled: true
  # 这里填写集群内 Falcosidekick 或现有接收器的地址
  url: "http://falcosidekick:2801/"

# 只给已有规则补充公共字段时使用；不会替换原规则的 output
append_output:
  - match:
      source: syscall
    extra_output: "source=runtime"
    extra_fields:
      - "k8s.ns.name"

append_output 适合给一组既有规则追加共同字段；如果必须替换某条规则的输出，需要在后加载的规则文件里使用 override，并明确记录这是字段兼容变更。生产环境通过 HTTPS、证书校验或集群网络策略保护 HTTP 输出，示例中的明文地址只用于表达配置关系。

用 Helm 把更新和回滚放进同一份配置

Kubernetes 部署时，可以把自定义规则写进 Helm values 的 customRules，让 chart 把它们放到 Falco Pod 的 /etc/falco/rules.d。告警出口也放在同一份变更里，代码审查时就能同时看到“规则增加了什么”和“事件会送到哪里”。

# values.yaml：规则文件和 Falcosidekick 入口属于同一次可回滚变更
customRules:
  runtime-rules.yaml: |-
    - rule: Container shell started
      desc: 容器内启动 shell 时生成运行时事件
      condition: spawned_process and container and proc.name in (sh, bash, ash)
      output: 容器内启动 shell (user=%user.name pod=%k8s.pod.name)
      priority: WARNING
      tags: [container, shell, runtime]

# 启用 Falcosidekick，由 chart 负责把 Falco 事件接到转发器
falcosidekick:
  enabled: true

# 与 Falcosidekick 对接时启用 JSON 和 HTTP 输出
jsonOutput: true
jsonIncludeOutputProperty: true
httpOutput:
  enabled: true
  url: "http://falcosidekick:2801/"

更新时把规则文件、Falco chart 配置和下游字段约定放在同一个变更单里。若新规则引入了新的字段或插件依赖，也要在规则文件中记录相应的兼容条件；不要只更新规则文件，却忘了下游解析器仍然按旧字段路由。

更新后按字段复查，而不是凭告警截图判断

Falco 官方安装文档提到，启用配置文件监视时，配置和规则文件变化可以触发重新加载；如果环境没有启用热加载，也可以按部署方式重启服务。下面的命令用于查看加载日志和部署状态，具体标签与命名空间应替换成自己的环境：

# 查看 Falco DaemonSet 的加载信息，确认规则文件没有被拒绝
kubectl logs -n falco daemonsets/falco

# 查看 Falco 与 Falcosidekick 的 Pod 状态，确认转发组件仍在工作
kubectl get pods -n falco -l app.kubernetes.io/part-of=falco

# 规则未启用热加载时，再按变更窗口重启 Falco DaemonSet
kubectl rollout restart daemonset/falco -n falco

复查应围绕事件字段建立清单：

如果加载日志正常但下游没有事件，先分开检查 HTTP 地址、网络策略、Falcosidekick 输入端口和下游路由；如果事件到达却被错误分组，再检查 rule、priority 和 tags，不要直接扩大规则条件。

常见问题

更新规则一定要重启 Falco 吗？

不一定。是否能热加载取决于配置和部署方式；先看当前环境的配置文件监视设置与加载日志。没有启用热加载时，再在变更窗口内重启对应服务或 DaemonSet。

为什么把自定义规则直接写进默认规则文件不合适？

默认规则通常由发行包或规则 artifact 管理，直接混写会让升级、回滚和冲突排查变复杂。把新增内容放进 rules.d 或 Helm 的 customRules，更容易单独审查。

新规则要不要单独创建一个告警平台入口？

通常不需要。只要新规则的 JSON 字段满足既有接收器约定，就继续沿用 HTTP 输出和 Falcosidekick；只有字段契约、吞吐或隔离要求确实不同，才考虑新增路由。

如何避免规则更新带来大量误报？

先缩小 condition 的事件边界，再用稳定的 priority 和 tags 观察下游聚合。对于已有规则的覆盖，确认文件加载顺序和 override 语义，避免用一个更宽的条件抢先匹配事件。