Kubernetes 运行时检测与执行约束工具
一次节点镜像升级后，安全看板仍显示所有传感器 Pod 为 Running，值班人员便认为运行时检测没有变化。直到容器里出现交互式 shell 而告警链毫无反应，团队才从启动日志里发现：新节点没有可读 BTF，安全策略又拒绝了 bpf()，探针进程虽然存活，却没有把内核事件送进规则引擎。DaemonSet 覆盖率、Pod Ready 与“事件真的可见”是三种不同证据。
另一次事故走向相反。平台团队为了阻止容器写入系统目录，直接把一条试验性执行策略推到所有节点。规则命中了镜像初始化脚本，多个工作负载同时启动失败；处置人员删除策略后，又没有确认 LSM 挂载点、节点代理和缓存策略是否收敛。安全工具从观察者变成执行者时，错误匹配、控制器延迟和回退失败都会进入业务故障半径。
先把安全动作拆成观察、判断和执行
运行时安全从工作负载已经开始执行之后产生事实。内核探针观察进程创建、系统调用、文件、网络或 LSM hook；用户态组件把底层事件补充为容器、Pod、namespace、镜像和进程树上下文；规则或策略判断行为是否值得记录、告警或阻止；输出链再把证据送往日志平台、SIEM 或响应系统。
这条链与准入控制并不重复。准入回答“这个对象能否写入 Kubernetes API”，运行时检测回答“对象启动以后实际做了什么”。镜像签名可以证明制品身份，却不能证明进程没有下载并执行新文件。静态清单扫描能发现 privileged: true，却看不到容器内谁在何时打开了敏感路径。把不同证据压成一个安全分数，会让调查人员无法判断缺的是配置事实、内核事实还是执行结果。
执行约束又比检测多了一步。Falco 和 Tracee 的核心是检测、告警与取证；Tetragon 可以用 TracingPolicy 描述观测并在适合的 hook 上采取执行动作；KubeArmor 依赖可用 LSM 落实工作负载或主机策略。工具名称并不能代替能力证明，真正的选择条件是目标内核提供什么 hook、节点允许什么权限、团队需要什么事件字段，以及一次错误阻断能影响多少业务。
从节点能力而不是产品名字开始
所有候选都运行在 Linux 节点附近，因而先受内核、发行版、容器运行时和集群安全策略约束。进入安装前，应在目标节点池抽样确认内核、BTF、BPF、LSM、cgroup 和符号信息。下面的命令不判定某个工具“支持或不支持”，而是生成能力事实，随后再与目标 release 的官方支持矩阵对照。
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
bpftool feature probe kernel 2>/dev/null | grep -E 'ringbuf|tracing|lsm' || true
kubectl get nodes -o wideBTF 让 CO-RE eBPF 程序适配目标内核类型；ring buffer 影响事件从内核向用户态的传递；/proc/kallsyms 会影响依赖内核符号的检测；LSM 列表决定 AppArmor、SELinux、BPF LSM 等执行 hook 是否存在。某项缺失不一定让整个传感器退出，常见结果反而是基础事件仍有、关键字段或高级检测悄悄消失。因此能力矩阵要记录“可用事件与字段”，不能只记录“能否启动”。
四类工具对应不同的证据重心
Falco 的优势是成熟的运行时规则模型、默认规则集与输出生态。它把 syscall 或插件事件送入规则引擎，命中后输出 rule、priority、tags 和字段，适合建设标准化告警链。Falco kernel event 架构解释了驱动、libscap、libsinsp 与规则引擎的关系。
Tracee 更强调 eBPF 事件、内置安全事件、Policy 作用域和取证上下文。团队需要沿进程、文件、网络和内核行为深入调查时，它提供的底层事件与 security event 很有价值；Policy 是事件选择与过滤模型，不是通用业务授权语言。Tracee Policy 文档适合核对 scope、rules 与 filters 的真实语义。
Tetragon 把 eBPF 可观测性与执行策略放在同一个体系中，TracingPolicy 能选择 hook、参数和动作。它可以独立部署，也常与 Cilium 组合；是否已经使用 Cilium 不是唯一选择条件，内核能力、事件导出、策略故障半径和升级耦合更重要。Tetragon 概念文档给出了传感器、策略和事件模型。
KubeArmor 以 workload policy、cluster policy 和 host policy 表达进程、文件、网络与 capability 约束，并依赖节点可用的 LSM 或合适回退路径。它适合把明确、窄化、经过反例验证的行为边界落实到执行层；若节点池的 LSM 不一致，策略语义也可能不一致。KubeArmor 支持矩阵应与真实节点探测结果一起评审。
安装权限决定了故障半径
运行时传感器通常以 DaemonSet 覆盖节点，并需要 host PID、host mounts、runtime socket、BPF capability、内核模块或 privileged 权限中的一部分。安装者还要创建 ServiceAccount、RBAC、ConfigMap、CRD、webhook 或集群级策略资源。普通应用流水线不应长期持有这些权限，传感器 namespace 也不能成为租户自由写入的共享空间。
快速实验常用 privileged，是为了减少环境差异，不代表生产设计应永久保留同样权限。生产 values 要逐项解释：哪项 capability 用于加载程序，哪个只读挂载用于读取 BTF 或容器元数据，runtime socket 暴露了什么控制能力，host PID 是否必需，移除一项后哪些事件消失。最小权限不是删到 Pod 启不来，而是在目标事件能力与节点风险之间留下可验证的映射。
用正反事件证明检测链
正向实验应选择不会破坏宿主、可精确清理的行为，例如在隔离 Pod 中启动一次 shell、访问一个测试路径或执行官方 tester 的单一动作。证据至少关联节点、Pod、容器、进程、规则或策略版本和事件时间窗。一次命中只能证明目标路径可用，不能证明所有节点、所有事件和所有字段都正常。
反向实验更能揭示“假健康”。在一次性节点池移除必要 capability、阻止 BPF syscall、使用缺少 BTF 的节点，或让输出端返回 429/500；随后观察传感器日志、事件缺口、丢事件指标、重试和业务节点资源。预期结果应是可区分的失败：驱动加载失败不能表现为静默 Ready，下游故障不能让采集引擎退出，执行策略反例不能只产生模糊的“permission denied”。
kubectl get daemonset,pods -A -o wide \
| grep -E 'falco|tetragon|tracee|kubearmor'
kubectl get events -A --sort-by=.lastTimestamp | tail -n 80
kubectl top pods -A | grep -E 'falco|tetragon|tracee|kubearmor' || true
# 每个工具再按自己的标签查询启动、探针、规则和输出错误
kubectl logs -n <sensor-namespace> <sensor-pod> --tail=200 \
| grep -Ei 'BTF|BPF|LSM|policy|rule|drop|error|permission'项目接入从事件合同开始
业务团队真正消费的不是 DaemonSet，而是事件合同。平台应固定资产键，例如 cluster、node、namespace、workload UID、Pod UID、container ID 与 image digest；固定规则或策略身份；区分事件发生时间、传感器接收时间和下游入库时间；保留原始字段与归一化字段的映射。Pod 名会变化，标签会被修改，只靠它们无法长期关联一次事件。
接入 SIEM 或工单系统时，先用一条受控事件走完整链：原始事件可查询，告警路由命中预期租户，重复事件的聚合方式可解释，处理状态不会覆盖原始证据，关闭工单后仍能按规则版本复核。跨节点、跨事件源关联应由下游平台完成，因为单个传感器通常不提供全局时序与长期存储。
检测数据本身也是敏感资产
进程参数、环境变量、打开路径、网络地址、容器标签和 Kubernetes 元数据可能包含令牌、客户标识、数据库地址和内部拓扑。Tracee 的 exec environment、Falco 的输出字段、Tetragon 的参数捕获以及 KubeArmor 的日志都要按数据分类启用。更丰富的上下文会提高调查效率，也会扩大采集权限、事件体积与泄露风险。
输出凭证应放入 Secret 或外部密钥系统，按目标端点拆分权限并定期轮换。Webhook 采用 TLS、认证、超时和网络策略；调试日志与安全事件分流；原始事件、聚合告警和工单有不同保留周期。向聊天工具发送完整命令行通常不是好默认值，通知里保留事件 ID 和脱敏摘要，再由有权限的调查人员进入证据库查看详情。
容量成本由事件率和字段宽度共同决定
运行时探针消耗节点 CPU、不可分页内存、ring buffer、用户态队列和日志带宽。打开全部 syscall、宽泛路径匹配、堆栈、文件哈希或环境变量会同时放大采集、解析、序列化和存储成本。平均 CPU 很低也不能证明安全，高峰 fork/exec、容器批量启动或网络风暴可能造成 buffer 满、用户态来不及消费和 dropped events。
容量测试要按节点类型与业务峰值分层，记录每秒事件、每事件字节、CPU、内存、队列深度、丢事件、下游延迟和重复率。规则优化也不能只以“告警变少”为目标：过滤发生在内核、用户态解析前还是规则命中后，对资源节省的效果完全不同。两个传感器并行部署会重复采集和富化，必须先在代表性节点测量增量成本与重复告警，再决定是否用互补能力换取双倍数据面。
高可用首先是每个节点都有有效传感器
DaemonSet 的 HA 不是把同一节点放两个同类探针。关键指标是目标 Linux 节点中有多少实例已成功加载探针、加载了目标规则或策略，并能把事件交付到下游。tolerations、nodeSelector、架构镜像、污点、资源压力和滚动更新参数都会形成节点级观测空洞。
集中输出组件则需要另一套 HA：副本、负载均衡、队列、幂等、去重和持久化。传感器重启期间事件通常无法事后补采，下游重启却可以通过耐久队列减少丢失。把这两个故障域分开，才能判断应该增加节点覆盖、降低事件量，还是扩容转发与存储。
升级和退出要按一组版本事务处理
一次升级同时涉及 Chart、应用镜像、内核接口、规则或 Policy、CRD、输出 schema 和下游解析器。先在与生产内核一致的 canary 节点池部署候选组合，用相同正反事件比较命中、字段、资源和丢事件；再限制 DaemonSet 的并发不可用节点数滚动。回滚也要恢复整组组合，单独换回镜像无法修复已经迁移的字段或规则。
退出前先停止新策略发布与自动响应，导出规则、Policy 和必要证据，再卸载 namespaced 资源。随后检查 CRD、ClusterRole、ClusterRoleBinding、webhook、finalizer、节点模块、BPF 程序、systemd 服务、日志索引和外部凭证。删除 namespace 只是控制面动作；直到节点探针、集群权限、下游入口和费用都完成核销，工具才真正离开系统。
架构选择落在可证明的不变量上
成熟团队不会争论“哪个工具功能最多”，而会写下希望长期成立的不变量：目标节点都有有效探针；关键行为有稳定事件字段；规则升级不会制造不可解释漏报；执行策略错误不会跨租户放大；下游短时故障不摧毁本地检测；敏感字段只进入授权存储；升级与退出都有可逆路径。
Falco 适合从规则与告警生态建立标准检测链，Tracee 适合更深的 Linux 事件与取证，Tetragon 适合需要精细 eBPF 观测并谨慎引入执行动作的团队，KubeArmor 适合围绕 LSM 建立明确行为约束。节点能力、事件合同、故障半径和团队维护能力会给出答案；产品标签不会。