Kubernetes 运行时安全的核心问题，不是“是否能够看到更多内核事件”，而是“这些事件能否被稳定地转化为可解释、可审计、可处置的安全信号”。eBPF 让安全代理可以在较低开销下观察系统调用、进程生命周期、网络连接、文件访问与部分内核安全钩子；Falco、Tetragon 等工具则把这些观察能力连接到容器、Pod、Namespace、镜像和工作负载身份上。它们显著改善了传统主机审计在云原生环境中的语义缺口，但并不自动等同于完整的入侵检测、策略执行或事件响应体系。
本文以工程边界为中心讨论 Kubernetes 运行时检测：哪些行为适合由 eBPF 捕获，哪些判断必须依赖 Kubernetes metadata enrichment，检测和阻断之间的责任边界如何划分，规则如何进入生命周期管理，误报如何治理，以及运行时信号如何进入审计与响应闭环。这里不讨论攻击操作路径，也不把任何单一工具描述为“银弹”。在生产环境中，运行时安全更接近一条事件链：内核事实、上下文补全、规则判定、告警分级、人工或自动响应、复盘与规则修订，任何一环薄弱都会降低整体有效性。
1. 从内核事实到安全语义
eBPF 运行时检测首先处理的是“事实层”数据。典型事件包括进程启动、参数、父子进程关系、命名空间标识、文件打开和写入、网络连接、DNS 访问、能力变更、部分 LSM 钩子事件等。这些事件的价值在于接近真实执行路径：它们发生在容器镜像扫描、Admission Control 或 IaC 检查之后，能够覆盖部署后才出现的配置漂移、人工调试、供应链运行态偏差和应用被利用后的异常行为。
但事实层数据本身并不等于安全结论。同样是一个 shell 进程，在一次受控的调试窗口中可能是授权维护行为；在只读业务容器内、由 Web 服务进程派生、伴随异常外联和敏感路径访问时，则可能是需要立即调查的高风险信号。同样是写入系统目录，在初始化容器、DaemonSet、构建任务、CI Runner 或业务容器中的含义也完全不同。因此，运行时检测的边界不应只用“能捕获什么 syscall”来定义，而应同时考虑“能否证明它属于哪个工作负载、哪个镜像版本、哪个变更窗口、哪个责任团队”。
Falco 的传统优势在于规则表达和事件流告警生态。它通过 syscall 或现代 eBPF 驱动采集事件，并用相对易读的规则描述异常模式，例如容器内启动交互式 shell、写入敏感目录、从非预期进程建立网络连接等。Tetragon 更强调基于 eBPF 的可观测性与策略化事件选择，常与 Cilium 网络和身份模型配合，提供进程、网络、文件及 Kubernetes 身份的关联视图，并支持在部分场景下把观测推进到执行控制。两者的差异不是简单的“谁更先进”，而是检测模型、规则工作流、网络身份集成和执行边界不同。
2. syscall、进程、网络与文件：可见性不是均匀分布
syscall 观察适合发现运行态偏差，但它天然存在粒度和解释成本问题。系统调用非常多，噪声也高；如果不做内核侧过滤、事件聚合和字段裁剪，很容易把安全管道变成高成本日志管道。生产实践中，通常应优先关注低频、高价值、具有明确语义的事件类别：进程执行、权限相关操作、敏感文件路径访问、容器逃逸相关边界条件、异常网络连接、运行中安装工具或修改配置等。对高频文件读写、普通网络收发包和无上下文的参数记录，应谨慎启用，避免性能和隐私成本失控。
进程链是运行时检测中最稳定的线索之一。父进程、可执行文件路径、命令参数、工作目录、容器身份、用户 ID、capabilities、TTY 信息、启动时间和镜像基线能够组成一条较完整的行为证据链。对于 Kubernetes 工作负载而言，很多风险不是来自单个进程名，而是来自“进程关系不符合应用角色”。例如，长期运行的 Web 服务、消息消费者、批处理任务和运维 DaemonSet 的进程谱系不同；规则应尽量围绕工作负载类型和已知基线构建，而不是仅依赖通用黑名单。
网络事件的检测边界更加依赖环境。eBPF 可以捕获连接发起、目标地址、端口、协议、DNS 查询及部分 L7 上下文；如果结合 CNI、Service、NetworkPolicy、身份标签和流量基线，可以识别异常外联、跨 Namespace 访问、非预期服务发现等问题。然而，网络事件单独使用时容易产生误读：Pod IP 生命周期短、NAT 和代理会改变可见路径，Service Mesh 会引入 sidecar 连接，DNS 缓存和连接复用也会影响事件解释。因此，网络检测应尽量与 Kubernetes Service、Endpoint、身份标签和变更记录联动，而不是只根据 IP 地址或端口做静态判断。
文件事件适合监控敏感路径和配置漂移，但同样需要控制范围。对 /etc、证书目录、服务账户令牌、二进制目录、包管理器路径、应用配置目录等进行写入或权限变更监控，通常比全量文件审计更有价值。容器文件系统的 overlay 特性、只读根文件系统、ConfigMap/Secret 挂载、emptyDir 和持久卷都会影响事件语义。一个可操作的原则是：规则不应只描述“访问了某路径”，还应描述“哪个工作负载在什么生命周期阶段以何种方式访问”。
3. Kubernetes metadata enrichment 决定信号质量
运行时安全工具在 Kubernetes 中的关键能力，是把内核层事件映射回 Kubernetes 对象。没有 enrichment，安全团队看到的是 PID、cgroup、inode、IP、路径和命名空间；有 enrichment，事件才能变成“某 Namespace 下某 Deployment 的某个 Pod，运行某镜像 digest，在某节点上由某 ServiceAccount 发起了某行为”。这种映射决定了告警能否分派、能否关联发布变更、能否进入审计证据链。
Metadata enrichment 至少应覆盖 Pod、Namespace、Node、Container、Image、Image digest、ServiceAccount、labels、annotations、owner reference 和容器运行时 ID。更成熟的实现还会关联集群名称、环境、团队归属、风险分级、准入策略结果、镜像扫描结果、变更单或 Git 提交。Falco 和 Tetragon 都可以利用 Kubernetes 上下文增强事件，但工程重点不只是“字段是否存在”，而是字段是否稳定、及时、可查询，并能在 Pod 重建、节点重启、控制面延迟和高负载下保持正确。
这里有一个常见误区：认为运行时检测只要部署 DaemonSet 即可完成。实际上，安全代理需要访问 Kubernetes API、容器运行时、内核能力和节点信息；这些权限本身也构成安全面。部署时应最小化 RBAC，明确节点权限边界，限制代理可写范围，保护规则和输出通道，避免把安全组件变成新的高权限盲点。对于多租户集群，还应区分平台团队、业务团队和安全团队的可见性边界，避免告警中泄露不必要的参数、环境变量或业务敏感数据。
4. Detection 与 enforcement：不要混淆两个控制面
检测回答“发生了什么，是否值得调查”；执行控制回答“是否允许继续发生”。二者可以共享事件源和策略语言，但工程目标不同。检测更强调覆盖率、证据完整性、可解释性和低漏报；enforcement 更强调确定性、低误杀、失败模式和回滚路径。把检测规则直接转成阻断规则，通常是高风险做法，尤其是在规则尚未完成基线学习、例外治理和变更验证前。
Falco 典型上处于检测与告警侧：规则命中后输出事件，由下游系统完成通知、工单、自动化响应或编排。它可以通过外部响应组件触发隔离、扩缩容、删除 Pod、调整 NetworkPolicy 等动作，但这些动作不应被视为 Falco 规则本身的天然结果。Tetragon 在一些场景中更接近“观测与执行一体化”，例如基于策略选择事件，并在支持的钩子上执行限制或终止动作。然而，即使工具支持 enforcement，也需要把策略分层：先观察，再告警，再人工审批或灰度阻断，最后才进入自动化处置。
一个可靠的分层模型可以分为四级。第一级是记录，仅用于取证和基线；第二级是告警，要求有明确 owner 和响应 SLA；第三级是受控响应，如打标签、隔离到受限网络、触发镜像回滚或暂停发布；第四级才是实时阻断或终止。不同规则应明确所在级别，并记录升级条件。对于业务关键路径，默认应避免在缺少演练和回滚机制时启用强阻断；对于明确违反平台安全边界的行为，例如非授权特权容器、敏感主机路径写入、禁止的内核能力使用，则可以更早进入强控制。
5. 规则生命周期：从默认规则到组织语义
默认规则集的价值在于提供起点，而不是最终答案。通用规则通常覆盖容器逃逸迹象、敏感文件访问、异常 shell、包管理器使用、内核模块操作、凭据路径读取等模式；这些规则可以快速建立最小检测面，但也会带来业务差异导致的误报。组织真正需要的是把默认规则翻译成自己的运行时语义：哪些 Namespace 是平台系统，哪些镜像允许调试工具，哪些 Job 会动态生成脚本，哪些团队拥有例外，哪些行为在生产环境永远不应出现。
规则生命周期应像应用代码一样管理。规则需要版本控制、评审、测试、灰度、回滚和变更记录。每条规则至少应包含目的、适用范围、严重级别、例外条件、证据字段、owner、预期响应和验证方法。对于 Falco，这意味着维护规则文件、宏、列表和 override 策略，避免在本地临时修改默认规则后失去升级能力。对于 Tetragon，这意味着维护 TracingPolicy、selectors、Kubernetes 资源范围和响应动作，并验证策略对节点性能和事件量的影响。
规则测试不应只依赖语法校验。更重要的是用代表性工作负载回放或在预生产环境观察事件量、字段完整性和命中分布。安全团队应建立规则准入门槛：命中后是否能说明风险；是否能定位到工作负载 owner；是否提供足够证据供一线值班判断；是否有明确的降噪条件；是否会采集敏感参数；是否在集群升级、内核升级、容器运行时升级后仍然有效。没有这些约束，规则库会很快演化成难以维护的告警噪声源。
6. 误报治理：从“关闭规则”到“改进证据”
误报不是单纯的规则问题，通常是上下文不足、资产归属不清、基线缺失或响应流程不成熟的表现。治理误报的目标不是把告警数量降到最低，而是提升每条告警的可行动性。一个有价值的运行时告警应回答五个问题：发生了什么；发生在哪个工作负载；为什么不符合预期；影响范围可能是什么；下一步由谁处理。
常见降噪方法包括基于 Namespace、labels、ServiceAccount、镜像 digest、命令参数、父进程、时间窗口和发布窗口做条件化；把临时调试行为绑定到审批记录；对平台组件和业务组件使用不同规则阈值；对高频低风险事件做聚合；对缺少处置动作的规则降级为审计日志。需要避免的做法是无期限地把整个 Namespace 或镜像加入白名单。例外应有到期时间、责任人和理由，并在镜像或工作负载变更时重新评估。
误报治理还需要指标。建议至少跟踪告警量、有效告警率、重复告警率、平均确认时间、平均处置时间、规则变更次数、例外数量、过期例外比例、事件丢失率和 agent 资源消耗。对运行时安全来说，性能指标也是安全指标：如果节点高负载时事件被丢弃，或者 agent 因资源限制重启，检测覆盖就会出现盲区。生产集群应监控 eBPF agent 自身的健康状态、buffer 丢包、Kubernetes API 同步延迟和输出管道积压。
7. 审计与响应闭环
运行时检测的最终形态应是闭环，而不是告警流。闭环至少包含事件记录、证据保全、分派、调查、处置、复盘和规则更新。事件进入 SIEM、日志平台或 case system 时，应保留原始字段和 enriched 字段，避免只保存一段不可结构化文本。关键字段包括集群、节点、Namespace、Pod、容器、镜像 digest、进程树、用户、命令摘要、文件路径、网络目标、规则版本、严重级别、事件时间和采集代理版本。
响应动作要与风险级别匹配。低风险事件可以进入趋势分析或周报；中风险事件应创建工单并要求 owner 确认；高风险事件需要平台和安全团队协作，可能包括冻结发布、隔离网络、保留 Pod 状态、抓取必要日志、回滚镜像或吊销凭据。所有自动化动作都应可追踪、可回滚，并避免破坏取证证据。尤其在 Kubernetes 中，直接删除 Pod 虽然简单，却可能丢失现场；更合适的策略可能是隔离、快照相关状态、复制日志，再按预案处置。
审计角度还要求证明控制持续有效。安全团队需要能够回答：哪些集群部署了运行时检测；哪些节点未覆盖；规则版本是什么；最近一次规则测试何时完成；哪些高危规则处于仅记录模式；哪些例外已过期；过去一个周期内哪些事件导致规则调整。对于受监管环境，这些问题往往比单次告警更重要，因为它们证明了运行时安全能力不是临时脚本，而是组织控制体系的一部分。
8. 工程选型：Falco、Tetragon 与组合使用
选择 Falco 或 Tetragon 时，应从现有平台能力出发。若团队需要成熟的规则生态、清晰的告警语言、较低的接入门槛，以及与现有 SIEM、告警和合规流程连接，Falco 通常是稳健起点。若团队已经使用 Cilium，重视网络身份、eBPF 可观测性和更细粒度的事件选择，并希望在部分路径上探索策略化响应，Tetragon 可能更自然。两者也可以组合：Falco 承担广泛规则检测和合规告警，Tetragon 承担特定工作负载的深度进程/网络追踪或与 Cilium 身份强相关的策略观察。
组合使用时要避免重复采集和重复告警。应明确每个工具的责任域、事件输出格式、严重级别映射和 owner。对于同一类行为，不建议在多个系统中维护语义不同的规则；更好的方式是让一个系统成为主检测源，另一个系统提供补充上下文或特定场景能力。平台团队还应评估内核版本、节点规模、容器运行时、托管 Kubernetes 限制、agent 资源开销、升级节奏和供应商支持。eBPF 工具对内核能力敏感，生产部署前必须验证兼容性和失败模式。
9. 可操作的落地顺序
一条稳健的落地路径通常从资产和基线开始。第一阶段只启用记录和少量高置信规则，确认节点覆盖、metadata enrichment、输出管道和 agent 健康。第二阶段建立默认规则集的组织化 override，把明确无害的系统行为降噪，同时保留敏感路径、异常进程和非预期网络行为。第三阶段接入工单和响应流程，要求每类高严重级别告警都有 owner、SLA 和处置手册。第四阶段才考虑在有限范围内启用自动化响应或 enforcement，并通过演练验证回滚。
在这个过程中，安全团队需要坚持两个原则。第一，运行时检测不是替代左移安全、准入控制、镜像签名、最小权限和网络策略；它是对“已运行事实”的最后一层观察和反馈。第二，eBPF 提供的是高质量遥测基础，而不是自动判断业务风险的魔法。真正决定效果的是上下文建模、规则治理、误报处理和响应纪律。
Kubernetes 运行时安全的检测边界，最终落在“可证明的上下文”和“可执行的流程”上。Falco、Tetragon 与 eBPF 事件链能够把内核事实带到安全团队面前，但只有当这些事实被映射到工作负载身份、规则生命周期、审计证据和响应闭环中时，才会成为生产环境中可靠的防御能力。否则，更多事件只会制造更多噪声；而经过治理的事件链，才能让运行时安全从告警系统变成持续改进的控制系统。
