3. Cilium 网络策略模型:L3/L4/L7 网络策略概述、基于 Identity 的安全模型、与传统 NetworkPolicy 的对比

Cilium 的网络策略模型是云原生安全的核心。与仅依赖 Pod IP 和端口的传统 Kubernetes NetworkPolicy 不同,Cilium 引入了基于 Identity(身份) 的安全模型,并支持从 L3 到 L7 的精细化控制。本章将深入解析这一模型的架构、核心概念及其与传统方案的差异。

3.1 基于 Identity 的安全模型:超越 IP 的安全基石

传统 Kubernetes NetworkPolicy 基于 Pod 的 IP 地址进行匹配。在动态的容器环境中,Pod 频繁创建和销毁,IP 地址不断变化,导致策略维护成本高且容易出错。Cilium 通过 eBPF 实现了革命性的 基于 Identity 的安全模型。

核心思想: Cilium 为每个 Pod 或端点分配一个全局唯一的 64 位数字标识符(Security Identity)。该 Identity 基于 Pod 的标签(Labels)计算得出,而非 IP 地址。所有网络策略均基于此 Identity 进行匹配和强制执行。

Identity 的生命周期与优势:

  • 动态分配: 当 Pod 启动时,Cilium Agent 根据其标签计算 Identity,并通过 KV Store(如 etcd)进行全局同步。
  • 策略解耦: 策略定义与 IP 地址完全解耦。即使 Pod 被调度到不同节点或 IP 发生变化,只要其标签不变,Identity 不变,策略依然生效。
  • 大规模性能: eBPF 程序在内核中直接处理 Identity 映射,避免了传统 iptables 规则链的线性匹配开销,显著提升了大规模集群下的策略执行性能。
Cilium 基于 Identity 的安全模型架构 Cilium 基于 Identity 的安全模型架构 Pod A 标签: app=frontend IP: 10.0.1.5 Cilium Agent 标签 → Identity Identity: 1001 eBPF 内核程序 匹配 Identity 1001 执行策略规则 关键优势 • 策略与 IP 解耦:Pod 重建或迁移后,只要标签不变,策略自动生效。 • 高性能:eBPF 在内核态直接处理 Identity,避免 iptables 规则链遍历。 • 全局唯一:Identity 在集群范围内唯一,支持跨节点策略一致性。

3.2 L3/L4 与 L7 网络策略:分层控制模型

Cilium 网络策略遵循 OSI 模型的分层思想,允许用户从网络层(L3)、传输层(L4)到应用层(L7)进行逐层精细控制。这种分层模型使得安全策略既可以是粗粒度的网络隔离,也可以是细粒度的 API 级访问控制。

策略层级 控制粒度 匹配依据 典型场景
L3 网络层 IP 地址 / CIDR 源/目的 IP 地址、IP 协议 集群与外部网络之间的基本隔离,如允许特定外部 IP 访问。
L4 传输层 端口 / 协议 源/目的端口、TCP/UDP/SCTP 协议 微服务间基于端口的访问控制,如只允许 80 端口流量。
L7 应用层 HTTP 方法 / 路径 / 头部 HTTP/gRPC/Kafka/DNS 等应用协议字段 精细的 API 安全,如只允许 GET /api/v1/users 请求。
实践建议: 在安全评审中,建议采用“由粗到细”的策略演进路径。先使用 L3/L4 策略实现基础隔离,再针对关键服务逐步叠加 L7 策略,以平衡安全性与运维复杂度。

3.3 与传统 Kubernetes NetworkPolicy 的对比

Kubernetes 原生 NetworkPolicy 提供了基础的 L3/L4 隔离能力,但在动态性、性能和 L7 支持方面存在明显局限。Cilium 网络策略在多个维度上进行了扩展和增强。

Cilium 网络策略 vs 传统 Kubernetes NetworkPolicy Cilium 网络策略 vs 传统 Kubernetes NetworkPolicy 传统 Kubernetes NetworkPolicy • 基于 IP 地址匹配 • 仅支持 L3/L4 控制 • 依赖 iptables 实现,性能随规则增长下降 • 不支持 L7 协议解析 Cilium NetworkPolicy • 基于 Identity 匹配,与 IP 解耦 • 支持 L3/L4/L7 全栈控制 • 基于 eBPF 实现,高性能且可扩展 • 原生支持 HTTP/gRPC/Kafka 等 L7 协议 升级 核心差异总结 1. 匹配模型:传统策略依赖 Pod IP(动态变化),Cilium 依赖 Identity(基于标签,稳定)。 2. 协议支持:传统策略仅支持 TCP/UDP/SCTP 端口;Cilium 额外支持 HTTP 方法、路径、gRPC 服务等。 3. 性能:传统 iptables 规则链在数千条规则时性能急剧下降;Cilium eBPF 哈希表查找,O(1) 复杂度。 4. 可观测性:Cilium 通过 Hubble 提供基于 Identity 的流量监控和策略审计,传统策略缺乏原生可观测性。

3.4 策略模型对比清单

以下清单总结了 Cilium 网络策略与传统 Kubernetes NetworkPolicy 在关键维度上的差异,便于安全评审时快速评估。

对比维度 传统 Kubernetes NetworkPolicy Cilium NetworkPolicy
匹配标识 Pod IP + 标签选择器 Security Identity(基于标签计算)
L3 支持 支持(IPBlock) 支持(CIDR 规则)
L4 支持 支持(端口 + 协议) 支持(端口 + 协议)
L7 支持 不支持 支持(HTTP/gRPC/Kafka/DNS 等)
数据路径 iptables / IPVS eBPF(内核态)
策略生效速度 秒级(规则更新需重建) 毫秒级(eBPF 程序热更新)
大规模性能 线性下降(规则链遍历) 常数级(哈希表查找)
可观测性 无原生支持 Hubble 提供全量流量与策略审计
安全评审注意: 在迁移或新建集群时,如果仅使用传统 NetworkPolicy,将无法对微服务间的 API 调用进行细粒度控制。对于金融、医疗等合规要求高的场景,建议优先采用 Cilium L7 策略,以实现对敏感数据访问的精确审计。