Falco、Tetragon、Tracee 与 KubeArmor 选型
一家平台团队同时部署了两个内核传感器，理由是“多装一个更安全”。上线后节点 CPU 抖动，两个系统对同一次 shell 启动生成不同事件：一个叫 rule 命中，一个叫 security event；下游按 Pod 名去重，又把滚动发布前后的两个 Pod 合并成同一事件。值班人员面对两套时间、字段和规则版本，反而无法证明攻击动作发生了几次。
另一家团队从检测工具迁移到带执行能力的方案，直接把旧告警规则翻译成阻断策略。测试时进程被 SIGKILL，面板显示 action 已执行，团队便认定文件写入被阻止。事故复盘发现 hook 触发时写入已经发生：终止进程、覆盖系统调用返回值和 LSM 拒绝不是同一种语义。迁移只翻译了规则文本，没有迁移证据合同与回退方式。
先决定需要哪一种运行时结果
运行时安全工具可以交付三种不同结果。第一种是检测：观察系统行为，用规则判断可疑并输出告警。第二种是深层可观测与取证：让安全工程师选择内核 hook、参数、进程树和上下文，回答行为如何发生。第三种是执行约束：在节点内核可支持的边界内拒绝进程、文件、网络或 capability 行为。把三者统称为“运行时防护”，会让采购、权限和验收一起失真。
Falco 的主线是事件源、libscap/libsinsp、规则与告警输出；它默认检测，不直接把规则命中变成阻断。Tetragon 用 eBPF hook 与 TracingPolicy 提供深层观测，并可选择 Signal、Override 等执行动作。Tracee 用 eBPF 采集 Linux 行为，以 Policy、内置安全事件和丰富上下文服务检测与取证，不默认阻断。KubeArmor 用 KSP/CSP/HSP 表达工作负载与主机约束，再交给 BPF-LSM、AppArmor 或 SELinux 执行 Allow/Audit/Block。
因此首个选型问题不是“谁的规则多”，而是调查人员最终需要哪类证据：一条成熟可运营的告警、一个可追到内核函数参数的事件，还是一个能够用返回码证明拒绝的约束。如果同一团队同时需要这些结果，也应先明确主系统与补充系统，避免两个执行器同时阻断同一动作。
四条运行链决定了四种故障方式
Falco 从 modern eBPF 或 kmod 取得 syscall 事件，经过解析与状态富化后按 rule condition 求值，再写入 stdout、HTTP 或 Falcosidekick。它的典型失败是驱动未加载、buffer 丢事件、字段状态不完整、exception 过宽或输出背压。Falco Kernel Events 架构适合核对采集与规则链。
Tetragon 把 TracingPolicy 映射到 kprobe、tracepoint、uprobe、fentry 等 hook，在内核中完成 selector 过滤，再通过 ring buffer、gRPC、JSON 或指标导出。它的典型失败是 BTF/符号不匹配、verifier 或 attach 失败、hook/参数理解错误、导出过滤不一致，以及把 SIGKILL 误当成原子拒绝。TracingPolicy 概念说明了低层策略模型。
Tracee 通过 eBPF 采集 syscall、进程、文件、网络及内核事件，Policy 用 scope 选工作负载、用 rules 选事件、用 filter 缩小数据，再派生安全事件或输出取证上下文。它的典型失败是 BTF、kallsyms 或 runtime socket 缺失造成部分字段和检测不可用，宽 Policy 又容易制造事件洪峰。Tracee Policy 文档可用于确认稳定版字段。
KubeArmor 由 Operator/Snitch 探测节点、Daemon 关联工作负载并驱动 LSM，Relay 负责遥测聚合。它的典型失败是策略对象存在但 Active LSM 为空、异构 enforcer 语义不一致、default posture 误配，以及 Relay 可用被错当成节点执行有效。KubeArmor Runtime Enforcer给出了执行器边界。
用稳定发行线建立可比较基线
评估环境应固定 Falco 0.44.1、Tetragon v1.7.0、Tracee v0.24.1 与 KubeArmor v1.7.4 这样的稳定发行线，并分别记录 Chart、镜像 digest、规则或 Policy 版本。版本号不是“永远推荐”的结论，而是让输入可复核；升级前应回到各项目 Release 与 Chart 索引确认目标组合。
Falco 当前主驱动是 modern_ebpf 与 kmod，旧 legacy eBPF、gVisor engine 和 Falco gRPC output/server 不应继续进入新部署。Tetragon 属于 Cilium 项目家族，但独立部署不要求使用 Cilium CNI。Tracee 的稳定文档与 dev 文档可能存在输出配置差异，稳定版命令不能直接照搬 dev 结构。KubeArmor 的 GitHub latest 可能指向 RC，必须同时判断版本名、Release 页面和 Chart 索引。
helm search repo falcosecurity/falco --versions | Select-Object -First 5
helm search repo cilium/tetragon --versions | Select-Object -First 5
helm search repo aqua/tracee --versions | Select-Object -First 5
helm search repo kubearmor/kubearmor-operator --versions | Select-Object -First 5上面的 Select-Object 适合 PowerShell 管理终端；Linux shell 可替换为 head -n 5。版本证据还应包含 helm show chart、helm show values 与运行 Pod 的 imageID，防止固定 Chart 却由 values 中的可变 tag 拉到不同镜像。
先做节点能力普查再谈安装
四个工具都触达 Linux 内核，但最低要求和完整能力并不相同。平台应按节点池采集内核 build、CPU 架构、BTF、ring buffer、kallsyms、BPF-LSM、AppArmor/SELinux、cgroup、CRI、安全启动和托管平台限制。只写“Linux 5.x”无法说明任何一套策略是否真正可执行。
uname -a
test -r /sys/kernel/btf/vmlinux && echo BTF_OK || echo BTF_MISSING
test -r /proc/kallsyms && echo KALLSYMS_OK || echo KALLSYMS_MISSING
cat /sys/kernel/security/lsm 2>/dev/null || true
cat /proc/sys/kernel/perf_event_paranoid
grep -E 'CONFIG_(BPF|BPF_SYSCALL|BPF_LSM|DEBUG_INFO_BTF|BPF_KPROBE_OVERRIDE|CGROUP_BPF)=' \
/boot/config-"$(uname -r)" 2>/dev/null || true
sudo bpftool feature probe kernel 2>/dev/null | grep -E 'ringbuf|tracing|lsm'Falco modern eBPF 重点看 BTF、ring buffer 与 tracing program；kmod 还要求匹配 headers、DKMS、模块签名和完整特权。Tetragon 官方最低内核口径不能代表全部能力，BTF、目标 hook 和 CONFIG_BPF_KPROBE_OVERRIDE 会直接影响 Override。Tracee 的基础采集可用不代表依赖 kallsyms 的 hooked_syscall、hidden_kernel_module 等事件可用。KubeArmor 还需要确认活动 LSM；没有 enforcer 时可以观察，却不能用 Block 证明拒绝。
能力普查结果应成为调度标签或节点池约束。例如把“BPF-LSM 完整执行”“仅 AppArmor”“只支持 eBPF 观测”“禁止内核探针”分成不同池，再决定传感器与策略落点。否则一次节点镜像升级就可能把同一 DaemonSet 从完整能力悄悄降成部分能力。
安装权限与运行权限必须分账
安装者通常需要创建 namespace、DaemonSet、CRD、ClusterRole 和 webhook；运行中的 agent 则需要宿主 PID/cgroup、BPF、procfs、securityfs、runtime socket 或 host network 中的一部分。安全产品本身处于高价值攻击面，不能因为用途是安全就免除最小权限审计。
Falco modern eBPF 可使用细粒度 BPF、PERFMON、SYS_RESOURCE、SYS_PTRACE 能力，kmod 模式则需要更高特权。Tetragon Chart 默认 agent 为 privileged 且使用 host network，gRPC 默认 Unix socket 更收敛。Tracee 的快速实验常用 privileged，但生产需要按事件能力拆解 BPF、PERFMON、PTRACE、NET_ADMIN、SYSLOG 等 capability。KubeArmor 虽已去掉笼统 privileged，Daemon 的 LSM/BPF 与宿主访问、Operator 的集群 RBAC、Controller 的 patch 权限仍然很高。
安装 ServiceAccount、节点 agent、Operator/controller、日志采集器和只读调查员应分别建模。评估报告至少保存 ClusterRole diff、host mount、capability、seccomp/LSM、Service 暴露和网络出口。任何需要 TCP gRPC、webhook 或 SIEM 凭证的组件都要使用 Secret、mTLS、NetworkPolicy 和轮换，而不是把 token 写入 Helm 命令。
在隔离节点池逐步部署候选工具
一次评估只在小型、可重建的 Linux 节点池部署一个候选工具，先验证采集，再引入第二个用于资源对照。下面的安装入口固定版本，但 values 文件仍需显式限制 nodeSelector、tolerations、resources、输出和权限。不要把四条命令同时运行在生产集群。
# Falco：成熟规则与告警链
helm upgrade --install falco falcosecurity/falco \
-n runtime-eval --create-namespace --version 9.1.0 \
--set driver.kind=modern_ebpf -f falco-eval-values.yaml
# Tetragon：低层 hook 与可选执行
helm upgrade --install tetragon cilium/tetragon \
-n runtime-eval --version 1.7.0 -f tetragon-eval-values.yaml
# Tracee：eBPF 检测与取证
helm upgrade --install tracee aqua/tracee \
-n runtime-eval --version 0.24.1 -f tracee-eval-values.yaml
# KubeArmor：先装 Operator，再应用固定镜像的 KubeArmorConfig
helm upgrade --install kubearmor-operator kubearmor/kubearmor-operator \
-n runtime-eval --version v1.7.4 -f kubearmor-eval-values.yaml每次只保留当前候选的命令，并把 runtime-eval 是否符合 Chart 预期核对清楚；有些项目默认推荐专用 namespace 或 kube-system。预期的第一层证据是目标节点都有 Pod，第二层是内核 probe/driver/enforcer 成功，第三层是规则或 Policy 已加载，第四层才是受控事件到达下游。卸载当前候选并确认 BPF pin、内核模块、CRD、RBAC 和日志出口清理后，才能开始下一个候选，避免残留改变结果。
用统一字段合同比较事件质量
四个工具字段名不同，不能直接按 JSON key 对齐。先定义产品无关的事件合同：cluster、node、namespace、workload UID、Pod UID、container ID、image digest、process executable、arguments、parent identity、event type、action、result/errno、policy or rule ID、policy version、event time、ingest time、sensor version 和 enforcer/driver。Pod 名只适合展示，不适合作为去重主键。
Falco 应核对 rule、priority、tags 与 output_fields；Tetragon 应核对 process、binary、namespace/workload、hook/action 和 policy；Tracee 应核对 event name、policies.matched、context/data 与 threat 字段；KubeArmor 应核对 PolicyName、Action、Result、Enforcer、resource、Pod/container 身份。字段为空要区分“工具不采集”“当前内核不支持”“当前事件无值”“输出过滤删除”和“下游解析丢失”。
参数、环境变量、路径、进程凭据和 runtime socket 都可能暴露 secret、客户标识与内部拓扑。评估时默认关闭全量环境变量和无界参数采集，只为明确检测打开最少字段。文件 sink、gRPC、webhook 与控制台可能使用不同过滤器；例如 Tetragon 的文件 export denylist 不自动过滤 gRPC 流，不能用一个出口的脱敏配置代表所有出口。
正向实验要让四个候选观察同一动作
创建一个隔离 namespace 和一次性 BusyBox Pod，在同一节点执行一次 shell、一次文件读取和一次不匹配动作。每个候选使用最窄规则或 Policy，只观察，不执行。实验要记录实际节点、Pod UID、容器 ID、命令退出码和触发前后的时间窗。
kubectl create namespace runtime-selection-lab
kubectl run shell-lab -n runtime-selection-lab \
--image=busybox:1.36 --restart=Never -- sleep 3600
kubectl wait -n runtime-selection-lab --for=condition=Ready pod/shell-lab --timeout=120s
kubectl get pod shell-lab -n runtime-selection-lab \
-o jsonpath='{.metadata.uid}{"\t"}{.spec.nodeName}{"\n"}'
kubectl exec -n runtime-selection-lab shell-lab -- sh -c 'cat /etc/hostname >/dev/null'
kubectl exec -n runtime-selection-lab shell-lab -- trueFalco 的预期证据是目标 rule 命中且带容器/进程字段；Tetragon 的预期证据是 exec 或目标 hook 事件关联 namespace、Pod 与 binary；Tracee 的预期证据是选定 event 进入指定 Policy，非匹配动作不进入；KubeArmor 使用 Audit 时，动作成功且 alert 标明 Audit/Passed。没有事件时先检查探针、selector、输出过滤、时间窗和丢事件指标，不能立即放宽到全 syscall 或全局 scope。
评估结果应比较“同一事实能否稳定关联”和“缺字段时能否解释”，而不是比较谁输出行数最多。宽规则得到更多事件可能只是更高成本和更大敏感面。
反向实验要暴露错误机制
第一类反向实验是探针假健康：在一次性测试节点移除候选所需 capability，或使用缺少 BTF/Active LSM 的节点镜像。预期 Pod 可能仍 Running，但日志出现 BPF load、verifier、BTF、permission 或 enforcer 缺失；自定义健康门禁应把该节点标为不可用。
第二类反向实验是输出背压：让测试 webhook 返回有限数量的 429 或 500，持续生成受控事件，观察本地事件、重试、丢失、重复、队列深度和探针资源。Falcosidekick、Tetragon gRPC 消费端、Tracee webhook、KubeArmor Relay 都不能未经实验就宣称耐久或 Exactly Once。
第三类反向实验是执行语义。KubeArmor 在 Active LSM 节点用 Block 拒绝一个确定存在的无害二进制，预期返回 permission denied 且 alert 的 Enforcer/Result 一致；在无 Active LSM 节点重复动作，预期命令成功，这证明“Policy Created”不是执行证据。Tetragon 若测试 Sigkill，还必须检查目标文件或 socket 是否已经改变；只有适用且经 probe 验证的 Override 才能用于返回值拒绝实验。Tetragon Enforcement明确说明了这些动作边界。
检测、阻断与响应不能混成一个开关
需要成熟规则生态、多事件源插件和告警扇出时，Falco 通常更自然。Falcosidekick 适合汇聚与多目标转发，但它不是耐久队列；Falco Talon 是独立响应引擎且应按其成熟度谨慎采用。把 Falco 告警直接连接删除 Pod 动作，会把误报、重复投递和瞬时洪峰转成破坏性操作。
需要低层 hook、内核参数和精确行为观察时，Tetragon 表达力更强，也要求团队能理解内核函数、参数、BTF、selector 与 TOCTOU 风险。Signal 终止进程、Override 修改允许覆盖的返回值、NotifyEnforcer 交给执行路径，三者不能写成统一的“阻断”。
需要丰富 Linux 事件、内置安全事件和取证上下文时，Tracee 适合围绕 eBPF 行为调查构建策略。它的 Policy 是 scope/rules/filter 模型，不是通用业务授权；稳定基线还存在 Policy 数量和同一 Policy 内事件定义约束，宽 scope 会放大资源与敏感数据成本。
需要用较高层的 Pod/节点策略持续执行 process/file/network/capability 基线时，KubeArmor 更贴近平台治理。但 BPF-LSM、AppArmor、SELinux 的能力差异和 default posture 必须进入发布合同。一个 YAML 在所有节点被 API 接受，不代表所有节点得到相同约束。
组合部署先证明增量价值
Falco 与 Tracee 并行可能为同一 syscall 重复采集，Falco 与 Tetragon 也可能对同一 exec 输出两套事件。组合前先定义唯一增量：例如 Falco 承担通用告警基线，Tetragon 只观察规则抽象之外的特定 hook；或 KubeArmor 承担稳定工作负载约束，Tracee 只在事件响应期间提供限时取证。
双装评估至少比较单装与双装的节点 CPU、内存、BPF map、ring buffer 丢失、事件率、平均事件大小、下游写入和重复告警。重复事件应在保留原始 product event ID 的前提下按 workload UID、container ID、process identity、event type 和窄时间窗关联，不能删除任一原始证据。
两个执行器不应同时拒绝同一动作。否则返回码由谁产生、哪个策略先命中、删除哪一条才能恢复都难以判定。确需重叠时，要在独立节点池证明执行顺序、归因字段和逐产品回退，且指定唯一的阻断 owner。
容量与成本按节点和事件共同计算
运行时安全成本不只是许可证。节点侧有 CPU、内存、BPF map/ring buffer、内核兼容测试和滚动升级空窗；传输侧有事件带宽、TLS、队列与跨区流量；存储侧有索引、保留、查询和敏感数据删除；组织侧有规则 owner、误报分诊、内核升级验证和 24 小时响应责任。
容量模型至少记录节点数、每节点事件率、规则/Policy 数量、事件过滤前后比例、平均与 P99 事件大小、丢事件数、下游延迟和恢复时间。Falco dropped events 会破坏进程状态富化；Tetragon 应监控 ring buffer、queue、notify overflow 和 export rate-limit 丢失；Tracee 宽 Policy 与额外 hash/stack/env 会增加 CPU 和体积；KubeArmor 的 visibility、Audit 比例、alert throttling 与 Relay 内存必须一起测量。
安全事件减少不能直接解释为攻击减少，也可能是传感器失效、过滤扩大、节流或消费端断连。成本优化应从更窄的采集与规则、分层保留和稳定资产键开始，而不是静默丢弃无法解释的事件。
HA 是节点覆盖与证据交付的组合
四个候选的 agent 通常以 DaemonSet 覆盖节点，所以节点侧 HA 首先意味着“所有应保护节点都有实际可工作的传感器”，包括污点节点、arm64、专用节点池和升级中的新内核。副本数量相等只证明调度，不证明 probe、driver 或 enforcer 成功。
集中组件要单独处理。Falcosidekick/SIEM、Tetragon 外部 gRPC collector、Tracee webhook/Forward、KubeArmor Relay 的副本、队列、去重和持久化合同各不相同。Tetragon Operator 扩副本还需要 lease failover；KubeArmor Relay 没有可以直接推导无损多副本的官方合同。应分别故障注入单节点 agent、controller/operator、聚合层和下游，记录旧策略是否继续执行、新策略能否发布、事件是否缺失和恢复需要多久。
迁移先双跑检测再切执行
迁移分四步。第一步把旧规则和事件字段映射到产品无关合同，不急着翻译语法；第二步在隔离节点池让新工具只观察，对同一受控事件比较命中、漏报、字段与资源；第三步让新工具成为检测主系统，旧工具保持只读兜底并停止新增规则；第四步才在小故障域启用需要的执行动作。
迁移不能把 Falco rule 机械翻成 KubeArmor Block，也不能把 Tracee security event 机械翻成 Tetragon Sigkill。原规则可能表达“值得调查”，而不是“可以安全拒绝”；新执行器还会改变 errno、进程生命周期和应用恢复路径。每条执行策略都要有 Audit/monitor 阶段、匹配与不匹配动作、业务状态、目标对象状态和回切测试。
回退条件应量化：探针 CPU/内存越界、丢事件超过预算、关键规则漏报、业务错误率增加、执行归因不清、敏感字段越界或下游无法恢复。回退顺序是先切回 monitoring/Audit，确认业务恢复，再停止新工具输出与控制器，最后清理节点内核对象和外部索引；不能先删除 CRD 或 Operator。
升级与退出必须保留恢复证据
升级包应绑定 Chart、应用镜像、driver/enforcer、CRD schema、rule/Policy、CLI、输出 schema 和下游解析器。先在生产同构节点池 canary，重复能力探测、正反事件、背压和回退。Helm --atomic 只能帮助恢复部分 Kubernetes 对象，不能证明 CRD 可降级、BPF pin 已清理、kmod 已卸载或下游 schema 已回滚。
退出 Falco kmod 时要检查模块、DKMS 与 systemd 残留；退出 Tetragon 前要禁用 persistent enforcement，并检查 /sys/fs/bpf/tetragon 的 pin；退出 Tracee 前导出 Policy，清理 CRD/RBAC 与外部索引；退出 KubeArmor 前先把 default posture 回到 audit，删除阻断策略并逐节点证明行为恢复。四种工具的 Secret、客户端证书、webhook、日志索引、对象存储和网络出口也要核销。
最后的选择应能用一句工程合同表达，例如：“Falco 负责集群通用行为告警，节点探针与规则版本可证，事件进入耐久队列；KubeArmor 只在 BPF-LSM 节点池执行经过 Audit 灰度的工作负载基线。”只要合同能说明谁观察、谁判断、谁阻断、证据去哪里、失效时如何恢复，选型就不再是一张产品功能表，而是一套可以长期运营的运行时安全架构。