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 在内核中完成,无需修改应用程序代码。

Cilium 策略执行机制流程图 1. 用户提交策略 2. Cilium Operator 处理 3. 身份计算与分发 4. Cilium Agent 生成 BPF 程序 5. 加载到内核 eBPF Hook 6. 数据包匹配与执行

执行流程详解:

  1. 策略定义与分发: 用户通过 kubectl 创建 CiliumNetworkPolicy CRD 资源。
  2. Operator 处理: Cilium Operator 监听 API Server,将策略转换为内部表示,并计算涉及的安全身份。
  3. 身份同步: Operator 将策略和身份信息通过 Key-Value 存储(etcd 或 KVStore)分发给所有节点的 Cilium Agent。
  4. BPF 编译与加载: 每个节点的 Cilium Agent 将策略编译为高效的 eBPF 字节码,并通过 tc(Traffic Control)或 XDP 挂载到网络接口上。
  5. 内核态执行: 当数据包到达网络接口时,eBPF 程序在内核态直接执行策略匹配,决定允许、拒绝或重定向到代理(用于 L7 策略)。
关键洞察: 整个执行路径在数据平面是“零拷贝”和“零上下文切换”的(除 L7 代理外)。这种机制使得 Cilium 能够以极低的延迟处理数十万条策略,非常适合大规模集群的容量规划——网络延迟和 CPU 开销不会随着策略数量线性增长。