eBPF 在容器安全中的新角色
云原生安全：eBPF 在 Kubernetes 网络策略中的零侵入实践
容器安全正在从“为网络补规则”转向“在数据路径中理解行为”。eBPF 的新角色，不只是替代部分 iptables 转发与匹配逻辑，而是把策略执行、流量身份识别和运行时观测连接到同一条内核数据路径上。对安全团队而言，关键变化在于：策略不再只是静态的地址与端口清单，而可以围绕工作负载身份、通信方向和实际请求行为建立。
传统规则链的难点并非只有性能。Pod 生命周期短、地址不断变化，安全人员很难仅凭 IP 规则回答“谁在访问谁、为何被允许、异常请求从何处出现”。eBPF 程序可在流量经过网络接口及协议栈的关键位置收集上下文，并通过高效映射表参与决策。这使容器网络安全更接近持续校验：策略变更、连接建立、DNS 查询和通信依赖能够被关联起来，而不是分散在规则表、日志和抓包结果中。
从边界控制到身份控制
Kubernetes 原生 NetworkPolicy 适合表达基于标签的 L3/L4 隔离，但复杂业务往往需要更细的访问语义。以 Cilium 为代表的 eBPF 数据面，可以在兼容原生策略的基础上扩展更细粒度的控制能力，例如围绕 HTTP 方法、路径或 gRPC 方法定义访问范围。其价值不在于把每条请求都写成规则，而在于将“允许访问某个服务”收缩为“允许特定身份以必要方式访问该服务”。
这种能力尤其适合处理横向移动风险。攻击者即使获得某个容器的网络位置，也不应天然拥有对同集群服务的广泛访问权。基于身份和最小权限的策略，可将不必要的东西向通信直接压缩掉。
可观测性成为策略闭环
策略越细，误拦截的风险也越高。因此，eBPF 的另一项安全价值是零侵入观测。流量已经经过数据面，安全团队可以据此查看服务依赖、策略决策、错误与异常连接，而不必要求每个 Pod 注入额外组件或修改应用代码。Hubble 所呈现的流量视图，真正的用途是让策略从“先写后猜”变成“先观察、再收紧、持续验证”。
落地时不宜一开始就追求 L7 全覆盖。更稳妥的路径是先梳理现有通信关系，以 L3/L4 隔离替换粗放规则，再对高风险接口逐步引入细粒度控制。同时必须验证内核兼容性、DNS、负载均衡和跨集群通信，并保留清晰的回退方案。eBPF 不是自动生成安全性的技术，但它让安全策略终于有机会贴近容器运行时的真实行为。
参与讨论
eBPF 真能把安全策略写得更细吗？
如果内核版本不兼容，怎么回滚？
我们公司已经在用 Cilium，观测效果不错。
担心在高并发时会不会增加延迟。
想知道 Hubble 的流量视图到底展示哪些信息。
把 L3/L4 隔离先做好，再慢慢加 L7 控制，我赞同。
豆包，最小权限这思路确实治横向移动更准
@ 英招翼 对，攻击者拿到一个容器不等于拿到整片集群。先把东西向通信收一收，横向移动的路就窄多了。不过策略越细越容易误拦，建议先看清依赖再收紧～
有没有小团队快速上手的教程？
如果容器频繁重启，eBPF 的映射表会不会丢失？
看到可以基于身份控制，感觉安全层次提升了。
内核版本这块最头疼，老节点根本跑不起来
先观察再收紧这步太关键，一上来全开L7肯定炸
实测下来，CPU 开销好像不大，挺惊喜。
后续如果跨集群通信，策略同步会不会很麻烦？
DNS和负载均衡这两个坑，实际落地最容易被低估
@ 孤夜微光 确实，这两个环节一旦没梳理清楚，策略收紧时很容易把正常流量一起拦掉，落地前得先验证并留好回退方案。
真正难的是把服务身份维护准，不然最小权限也容易误拦截
@ 孤星照 对，身份漂移和服务变更一多，策略很容易从最小权限变成误拦截。先观测依赖、再逐步收紧会稳不少。