eBPF 在容器安全中的新角色

容器安全正在从“为网络补规则”转向“在数据路径中理解行为”。eBPF 的新角色，不只是替代部分 iptables 转发与匹配逻辑，而是把策略执行、流量身份识别和运行时观测连接到同一条内核数据路径上。对安全团队而言，关键变化在于：策略不再只是静态的地址与端口清单，而可以围绕工作负载身份、通信方向和实际请求行为建立。

传统规则链的难点并非只有性能。Pod 生命周期短、地址不断变化，安全人员很难仅凭 IP 规则回答“谁在访问谁、为何被允许、异常请求从何处出现”。eBPF 程序可在流量经过网络接口及协议栈的关键位置收集上下文，并通过高效映射表参与决策。这使容器网络安全更接近持续校验：策略变更、连接建立、DNS 查询和通信依赖能够被关联起来，而不是分散在规则表、日志和抓包结果中。

从边界控制到身份控制

Kubernetes 原生 NetworkPolicy 适合表达基于标签的 L3/L4 隔离，但复杂业务往往需要更细的访问语义。以 Cilium 为代表的 eBPF 数据面，可以在兼容原生策略的基础上扩展更细粒度的控制能力，例如围绕 HTTP 方法、路径或 gRPC 方法定义访问范围。其价值不在于把每条请求都写成规则，而在于将“允许访问某个服务”收缩为“允许特定身份以必要方式访问该服务”。

这种能力尤其适合处理横向移动风险。攻击者即使获得某个容器的网络位置，也不应天然拥有对同集群服务的广泛访问权。基于身份和最小权限的策略，可将不必要的东西向通信直接压缩掉。

可观测性成为策略闭环

策略越细，误拦截的风险也越高。因此，eBPF 的另一项安全价值是零侵入观测。流量已经经过数据面，安全团队可以据此查看服务依赖、策略决策、错误与异常连接，而不必要求每个 Pod 注入额外组件或修改应用代码。Hubble 所呈现的流量视图，真正的用途是让策略从“先写后猜”变成“先观察、再收紧、持续验证”。

落地时不宜一开始就追求 L7 全覆盖。更稳妥的路径是先梳理现有通信关系，以 L3/L4 隔离替换粗放规则，再对高风险接口逐步引入细粒度控制。同时必须验证内核兼容性、DNS、负载均衡和跨集群通信，并保留清晰的回退方案。eBPF 不是自动生成安全性的技术，但它让安全策略终于有机会贴近容器运行时的真实行为。