3. Cilium 网络策略模型:基于身份的安全策略、L3/L4/L7策略、策略执行机制
Cilium 的网络策略模型彻底改变了传统基于 IP 地址的网络安全范式。它利用 eBPF 的强大能力,将安全决策从“IP 地址”提升到“身份”层面,并支持从网络层到应用层的精细化控制。理解这一模型是进行云原生成本优化和容量规划的基础——精确的策略可以减少不必要的网络开销,提升资源利用率。
3.1 基于身份的安全策略(Identity-Based Security)
传统 Kubernetes NetworkPolicy 依赖 Pod 的 IP 地址和标签选择器。Cilium 则引入了 安全身份(Security Identity) 的概念,将一组具有相同安全属性的端点(Pod、节点、外部服务)抽象为一个身份。
核心优势: 当 Pod 重启或扩缩容导致 IP 地址变化时,Cilium 无需更新任何策略规则。策略始终绑定于身份,而非易变的 IP,这在大规模集群中显著降低了策略管理的复杂度和控制面压力。
身份分配机制如下:
- 基于标签派生: Cilium 根据 Pod 的 Kubernetes 标签(如
app=frontend)自动计算并分配一个 24 位的安全身份标识。 - 全局一致性: 在同一个 Cilium 集群中,具有相同标签集的 Pod 会被分配相同的身份,无论它们运行在哪个节点上。
- 身份到端点的映射: Cilium Agent 通过 eBPF Map 维护本地身份与端点列表的映射关系,实现高效的策略查找。
成本优化视角: 基于身份的策略减少了因 IP 变动导致的策略重计算和 API Server 负载。在容量规划时,这意味着控制面组件(如 kube-apiserver、cilium-operator)的资源需求更可预测,避免了因策略频繁更新带来的性能尖峰。
3.2 L3/L4 网络策略
Cilium 的 L3/L4 策略提供了传统网络层和传输层的访问控制,但以身份为基础进行表达。它定义了哪些身份可以访问哪些身份,以及允许的协议和端口。
以下是一个典型的 L3/L4 策略示例,允许带有 app=frontend 身份的 Pod 访问带有 app=backend 身份的 Pod 的 8080 TCP 端口:
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "l3-l4-allow-frontend-to-backend"
spec:
endpointSelector:
matchLabels:
app: backend
ingress:
- fromEndpoints:
- matchLabels:
app: frontend
toPorts:
- ports:
- port: "8080"
protocol: TCP
L3/L4 策略的关键特性:
| 特性 | 说明 | 对容量规划的影响 |
|---|---|---|
| 身份选择器 | 使用 fromEndpoints / toEndpoints 替代 IP CIDR |
减少因 IP 变化触发的策略同步,控制面更稳定 |
| 端口与协议 | 支持 TCP、UDP、SCTP,可指定端口范围 | 精确限制流量,避免不必要的广播和连接,降低网络带宽消耗 |
| 无状态/有状态 | 默认有状态,允许回程流量;可配置无状态模式 | 有状态模式减少显式规则数量,降低 eBPF Map 大小 |
3.3 L7 应用层策略
L7 策略将安全控制延伸到应用层,允许基于 HTTP 方法、路径、头部,以及 Kafka、gRPC 等协议字段进行访问控制。这通过 Cilium 的代理(Envoy)或原生 eBPF 解析实现。
以下是一个 L7 HTTP 策略示例,仅允许 GET /api/v1/items 请求:
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "l7-http-rule"
spec:
endpointSelector:
matchLabels:
app: service-a
ingress:
- fromEndpoints:
- matchLabels:
app: service-b
toPorts:
- ports:
- port: "8080"
protocol: TCP
rules:
http:
- method: "GET"
path: "/api/v1/items"
性能与成本权衡: L7 策略虽然提供了强大的可见性和控制力,但会引入额外的处理开销(代理模式增加延迟,eBPF 模式增加 CPU 消耗)。在容量规划时,必须为启用 L7 策略的工作负载预留额外的 CPU 资源,并评估其对吞吐量的影响。建议仅在关键业务路径上使用 L7 策略。
L3/L4 与 L7 策略对比:
| 维度 | L3/L4 策略 | L7 策略 |
|---|---|---|
| 控制粒度 | IP、端口、协议 | HTTP 方法、路径、头部、gRPC 服务、Kafka Topic |
| 性能开销 | 极低(纯 eBPF 内核态处理) | 中等至高(需代理或深度包检测) |
| 适用场景 | 微服务间基础网络隔离、数据库访问控制 | API 网关、微服务精细化权限管理、安全审计 |
| 资源消耗 | 几乎无额外 CPU/内存 | 需要额外 CPU 和内存资源 |
3.4 策略执行机制
Cilium 的策略执行是一个高效、分层的过程,完全基于 eBPF 在内核中完成,无需修改应用程序代码。
执行流程详解:
- 策略定义与分发: 用户通过
kubectl创建CiliumNetworkPolicyCRD 资源。 - Operator 处理: Cilium Operator 监听 API Server,将策略转换为内部表示,并计算涉及的安全身份。
- 身份同步: Operator 将策略和身份信息通过 Key-Value 存储(etcd 或 KVStore)分发给所有节点的 Cilium Agent。
- BPF 编译与加载: 每个节点的 Cilium Agent 将策略编译为高效的 eBPF 字节码,并通过
tc(Traffic Control)或XDP挂载到网络接口上。 - 内核态执行: 当数据包到达网络接口时,eBPF 程序在内核态直接执行策略匹配,决定允许、拒绝或重定向到代理(用于 L7 策略)。
关键洞察: 整个执行路径在数据平面是“零拷贝”和“零上下文切换”的(除 L7 代理外)。这种机制使得 Cilium 能够以极低的延迟处理数十万条策略,非常适合大规模集群的容量规划——网络延迟和 CPU 开销不会随着策略数量线性增长。