Falco 告警之后，Tetragon 能不能补上执行这一步？

2026 年 5 月，Falco 0.44.0 发布。这个版本不是常规的功能迭代，而是一次架构层面的"断尾"：legacy eBPF probe、gVisor 引擎、gRPC output 及 gRPC server 被彻底移除，modern eBPF（CO-RE，Compile Once - Run Everywhere）成为唯一支持的驱动。与此同时，Tetragon 1.7 继续强化其内核内执行（in-kernel enforcement）能力——TracingPolicy 可以直接在内核返回 -EPERM 或发送 SIGKILL，在 syscall 完成之前阻断进程。

这两个动作放在一起，很容易让人产生一个直觉：Falco 负责"看"，Tetragon 负责"杀"，两者拼起来就是一套完整的云原生运行时安全体系。但这个直觉忽略了一个关键问题：检测与执行在工程上的风险模型完全不同。Falco 的误报只会产生告警噪音，Tetragon 的误报可能直接杀死生产进程。本文从架构数据路径、规则语义差异、生产落地风险三个维度，拆解这对组合的互补边界与不能跨越的红线。

Falco 0.44 的断尾：从三种驱动到一种驱动的技术债务清理

Falco 的驱动演进史是云原生安全工具与 Linux 内核兼容性博弈的缩影。

早期 Falco 依赖内核模块（kernel module），这需要为目标内核版本编译 .ko 文件，运维负担沉重。随后引入的 legacy eBPF probe 虽然免去了内核模块的编译链，但仍需针对具体内核版本生成 probe，本质上是把编译问题从内核空间搬到了 eBPF 字节码层面。gVisor 引擎则试图覆盖沙箱化容器场景，但维护成本与使用面始终不成比例。

从 0.38.0 开始，Falco 引入 modern eBPF driver，基于 CO-RE 技术（Compile Once - Run Everywhere）和 BTF（BPF Type Format）信息，实现了一次编译、跨内核版本运行。0.41（2026 年 2 月）将其提升为默认驱动，0.42/0.43 逐步标记其他驱动为 deprecated，到 0.44（2026 年 5 月）则彻底移除。

这一变化对生产环境的影响是实质性的：

但有一个隐藏边界需要注意：CO-RE 依赖内核的 BTF 信息。如果运行的是自定义编译内核或某些裁剪版容器优化内核（如部分云厂商的定制内核），BTF 可能缺失，此时 Falco 无法启动。在生产环境推广前，必须先验证 cat /sys/kernel/btf/vmlinux 是否存在。这不是 Falco 的缺陷，而是 eBPF CO-RE 模型的通用约束。

驱动的统一化也意味着 Falco 维护团队可以集中资源优化单一路径。0.44 带来的新规则语言能力、性能提升和安全加固，都建立在"无需再兼容三条驱动分支"的前提之上。对于使用者而言，升级 0.44 前必须确认：是否还有工作负载依赖 legacy probe 或 gVisor 引擎。如果有，这不是一次平滑升级，而是一次架构迁移。

架构路径差异：用户空间规则引擎 vs 内核内策略过滤

Falco 和 Tetragon 都挂接在 eBPF 上，但数据离开内核后的路径完全不同，这决定了它们的性能特征和能力边界。

Falco 的数据流

Falco 的 modern eBPF driver 在内核中采集 syscall 事件，通过 perf/ring buffer 将原始事件传递到用户空间的 Falco 进程。用户空间的规则引擎（基于 YAML 规则语法）对每个事件进行评估，匹配则输出告警。告警可以通过 stdout、文件、HTTP webhook、Kubernetes audit events 等渠道发出。

这个架构的核心特征是：检测逻辑在用户空间执行。这意味着：

• 规则语法可以非常灵活，支持列表匹配、正则、容器镜像元数据关联、Kubernetes 字段过滤等复杂逻辑；
• 规则更新无需重新加载内核程序，重启 Falco 进程即可；
• 但每一次 syscall 事件都要经历内核 → 用户空间的上下文切换，高频率 syscall 场景（如大量文件 I/O 或网络连接）会产生明显的 CPU 开销。

Tetragon 的数据流

Tetragon 的内核 eBPF 程序不仅采集事件，还在内核内完成策略匹配和过滤。TracingPolicy 定义的规则被编译为 eBPF 字节码直接加载到内核。只有当事件匹配策略条件时，才通过 ring buffer 向用户空间发送已过滤的、聚合后的事件。更重要的是，Tetragon 支持在内核内直接执行动作：

• action: Sigkill — 向进程发送 SIGKILL
• action: Override — 返回自定义错误码（如 -EPERM），使 syscall 失败

这个架构的核心特征是：过滤和决策在内核内完成。这意味着：

• 大量无关事件不会离开内核，观测开销显著低于全量 syscall 导出；
• 执行动作（kill / block）发生在用户进程完成 syscall 之前，是真正的"实时阻断"；
• 但策略逻辑的复杂度受限于 eBPF 验证器的约束（循环限制、指令数上限、不允许任意内存访问），不能像用户空间程序那样自由表达复杂规则。

上图的关键差异在于"决策点"的位置。Falco 的决策点在用户空间，因此可以做更聪明的检测，但代价是上下文切换。Tetragon 的决策点在内核，因此可以执行，但规则表达能力受限。这不是孰优孰劣的问题，而是检测面与执行面天然需要不同的工程折中。

规则语义对比：从 Falco Rule 到 Tetragon TracingPolicy 不是直译

2026 年 1 月，Cilium 官方发布了一份从 Falco 向 Tetragon 迁移的指南。指南中给出的核心信息是：两者规则模型的语义存在结构性差异，不能一对一机械翻译。

Falco 规则的核心范式

Falco 规则围绕"条件表达式"构建。一条规则定义了什么条件下触发告警：

- rule: Terminal Shell in Container
  desc: Detect shell spawned inside a container
  condition: >
    spawned_process and
    container and
    (shell_procs or shell_mgmt_binaries)
  output: >
    Shell spawned in container
    (user=%user.name command=%proc.cmdline container=%container.name)
  priority: NOTICE

这种范式的特点是：

• condition 是一个逻辑表达式，可以组合多个宏（macro）和列表（list）；
• output 定义了告警格式，支持字段插值；
• 规则天然是"只读"的，只能观察不能干预；
• 社区规则库（falcosecurity/rules）非常成熟，覆盖 MITRE ATT&CK 多个战术。

Tetragon TracingPolicy 的核心范式

Tetragon 的 TracingPolicy 围绕"挂接点 + 匹配条件 + 动作"构建。一条策略定义了在什么内核事件上、满足什么条件时、执行什么动作：

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: "block-sensitive-file-access"
spec:
  kprobes:
  - call: "security_file_permission"
    syscall: false
    args:
    - index: 0
      type: "string"
    matchArgs:
    - index: 0
      operator: "Prefix"
      values:
      - "/etc/shadow"
    matchActions:
    - action: "Sigkill"

这种范式的特点是：

• call 指定内核挂接点（kprobe、tracepoint、uprobe），需要理解内核函数签名；
• matchArgs 是参数级匹配，操作符包括 Equal、Prefix、Postfix、Regexp；
• matchActions 定义执行动作，Sigkill 直接杀进程，Override 返回错误码；
• 策略可以直接作为 Kubernetes CRD 管理，支持 kubectl apply。

翻译的边界

Cilium 迁移指南中给出的示例展示了翻译思路：Falco 的 spawned_process and shell_procs 可以映射为 Tetragon 中对 execve 的挂接，并匹配二进制路径。但以下场景存在翻译困难：

关键结论：Falco 规则库中适合迁移到 Tetragon enforcement 的，只是那些原子性高、置信度高、条件简单的规则。行为链检测（如"先下载再执行再外联"的多阶段攻击）仍然更适合留在 Falco 的用户空间引擎中做关联分析。

生产落地路径：从 Observe-Only 到 Enforcement 的灰度策略

把 Tetragon 的 enforcement 能力直接投入生产，最大的风险不是技术故障，而是误杀。一个被正则表达式错误匹配的合法运维脚本、一个被路径规则误触的监控探针，都可能在高峰时段引发级联故障。因此，落地必须遵循严格的灰度路径。

第一阶段：Observe-Only 并行运行（2-4 周）

在同一集群中并行部署 Falco 和 Tetragon，但 Tetragon 的所有 TracingPolicy 只配置 action: Post（输出事件，不执行）。这一阶段的目标是：

1. 覆盖度验证：将 Tetragon 事件与 Falco 告警做交叉对比，确认策略触发的场景与预期一致；
2. 基线建立：统计正常业务负载下策略的触发频率，识别潜在的"正常但可疑"行为；
3. 噪音识别：某些在 Falco 中作为低优先级告警的规则，在 Tetragon 中如果转为 enforcement，其误杀代价完全不同，需要重新评估。

建议用以下脚本做每日交叉比对（概念示例，需根据实际日志格式调整）：

#!/bin/bash
# 概念：比对 Falco 告警与 Tetragon observe-only 事件的时间窗口重叠度
FALCO_LOG="/var/log/falco/alerts.json"
TETRAGON_LOG="/var/log/tetragon/tetragon.log"
 
# 提取过去 24 小时内 Falco 告警的 (timestamp, container, proc.cmdline)
jq -r 'select(.time >= (now - 86400)) | [.time, .output_fields."container.name", .output_fields."proc.cmdline"] | @tsv' "$FALCO_LOG" > /tmp/falco_24h.tsv
 
# 提取 Tetragon 同期事件
jq -r 'select(.time >= (now - 86400)) | [.time, .process.pod.name, .process.binary] | @tsv' "$TETRAGON_LOG" > /tmp/tetra_24h.tsv
 
# 计算重叠率（概念逻辑）
echo "Falco alerts: $(wc -l < /tmp/falco_24h.tsv)"
echo "Tetragon events: $(wc -l < /tmp/tetra_24h.tsv)"
echo "Overlap rate: $(python3 -c '...')"

注意：上述脚本为概念性设计，未在生产环境实测。实际实施时需根据 Falco 的 JSON output 格式和 Tetragon 的 JSON export 格式调整字段路径，并处理时区、容器名称截断等边界情况。

第二阶段：高置信度规则迁移（2-4 周）

选择两类最低误报风险的规则率先迁移为 enforcement：

1. 反向 shell 检测：容器内启动 /bin/bash -i 或 /bin/sh -i 并重定向到网络 fd。正常业务几乎不可能出现此行为；
2. 加密货币挖矿：匹配已知矿工程序的哈希或路径（如 xmrig、minerd）。可通过镜像扫描提前建立白名单。

这两类规则的共同特征是：行为特征明确、业务合法性极低、误杀后果可控。迁移时遵循"先告警后阻断"的递进：

# 阶段 2A：先告警（Post），观察一周
matchActions:
- action: Post
 
# 阶段 2B：确认无误报后，改为 Sigkill
matchActions:
- action: Sigkill

第三阶段：扩展与回滚机制

随着置信度积累，逐步将更多 Falco 规则迁移到 Tetragon。但必须保留：

• Falco 作为检测基线：即使某条规则已迁移到 Tetragon enforcement，仍建议在 Falco 中保留对应的 observe 规则，用于审计和覆盖度监控；
• 紧急回滚能力：TracingPolicy 是 Kubernetes CRD，可以通过 kubectl delete tracingpolicy <name> 在秒级撤销 enforcement，比修改 Falco 规则并重启 Pod 更快；
• 命名空间级灰度：利用 TracingPolicy 的 namespaceSelector，先在非生产命名空间验证，再推广到核心业务。

风险与边界：Execution 不是检测的升级版

把 Tetragon 的 enforcement 理解为"更厉害的 Falco"是一个危险的认知偏差。检测与执行之间的鸿沟，不只是技术实现差异，更是风险模型和运维契约的根本不同。

误报代价的不对称性

这个不对称性决定了：Tetragon 的策略数量应该远少于 Falco 的规则数量。Falco 社区规则库有数百条规则覆盖广泛的 MITRE ATT&CK 战术，而 Tetragon 在生产环境中适合保持 enforcement 策略在个位数到十位数级别，每条策略都经过充分的 observe-only 验证。

内核内执行的隐藏约束

Tetragon 的 Override 动作返回 -EPERM 时，是从内核直接修改 syscall 的返回值。这种方式对绝大多数 syscall 有效，但存在边界：

• 某些 syscall 不可重入：如果进程在收到 -EPERM 后没有正确处理错误码，可能导致未定义行为（如崩溃或死锁）；
• 信号投递的时序：Sigkill 不是即时生效的，内核需要找到合适的信号投递点。在极端高负载下，目标进程可能在收到信号前完成部分操作；
• eBPF 验证器限制：复杂的策略逻辑（如基于历史行为的状态机）无法在内核 eBPF 程序中表达，必须回到用户空间处理。

覆盖盲区的互补设计

Falco 和 Tetragon 各自有无法覆盖的场景，两者的组合才能形成相对完整的运行时安全面：

上图展示了理想的分层：Falco 的广泛检测产出大量低-中置信度告警，经过 SOC 分析或自动化规则升级后，部分高置信度场景转化为 Tetragon 的 enforcement 策略。Tetragon 的执行事件又回流到 Falco 的审计日志中，形成闭环。

结论

Falco 0.44 的断尾清理和 Tetragon 1.7+ 的执行强化，标志着云原生运行时安全从"单工具全能"走向"分层专精"。Falco 不再是那个需要维护三种驱动兼容性的沉重项目，而 Tetragon 也不再只是一个"更底层的 Falco"。

回到文章标题的问题：Falco 告警之后，Tetragon 能不能补上执行这一步？

答案是能，但有严格的适用范围。Tetragon 可以补上的，是那些经过充分验证、原子性高、误报代价可接受的执行动作——比如杀死一个反向 shell、阻止对敏感文件的访问。但它不能补上的，是复杂行为链的关联分析、低置信度场景的渐进式研判、以及广泛的威胁覆盖。这些仍然是 Falco 用户空间规则引擎的专长。

生产落地的核心判断不是"选 Falco 还是 Tetragon"，而是在检测面保留 Falco 的广度，在执行面收敛 Tetragon 的深度，中间用严格的灰度验证和回滚机制隔开。两者都通过 eBPF 进入内核，但一个选择把智慧放在用户空间，一个选择把力量放在内核空间——这种分工，才是云原生运行时安全的合理架构。

未闭合边界：

• eBPF CO-RE 在自定义内核上的兼容性验证方法尚未形成标准化工具链；
• Tetragon 的 Override 动作对某些特殊 syscall 的行为影响需要更系统的测试矩阵；
• Falco 规则库中适合迁移到 Tetragon enforcement 的规则的自动化识别方法，目前仍依赖人工判断。