3. Cilium 网络策略核心：Identity、Endpoint 选择器与策略模型

Cilium 网络策略的底层逻辑与 Kubernetes 原生 NetworkPolicy 有本质区别。Kubernetes 原生策略依赖 Pod IP 和标签选择器，而 Cilium 引入了 Identity（身份） 概念，将安全策略与 IP 解耦，使得策略在动态编排环境中更加稳定、高效。本章深入剖析 Identity 机制、Endpoint 选择器、L3/L4/L7 策略模型以及策略执行顺序，为后续资源画像与成本优化打下基础。

3.1 Identity 概念：策略与 IP 解耦的核心

在 Cilium 中，每个 Endpoint（Pod 或外部网络端点）都会被分配一个全局唯一的 Security Identity。这个 Identity 基于 Endpoint 的标签集合计算得出，并缓存在 Cilium Agent 的本地 BPF Map 中。当 Pod 的标签发生变化时，Identity 会重新计算并同步。

关键优势： 策略规则不再依赖 Pod IP（IP 会随 Pod 重启、迁移而变化），而是基于 Identity。这使得策略在集群扩缩容、节点故障、Pod 滚动更新时依然保持正确，大幅降低策略维护成本。
特性 Kubernetes 原生 NetworkPolicy Cilium NetworkPolicy (基于 Identity)
策略匹配依据 Pod IP + 标签选择器 Security Identity（基于标签计算）
IP 变化影响 策略可能失效，需重新同步 策略不变，Identity 自动更新
大规模集群性能 IP 规则数量随 Pod 数线性增长 Identity 数量远小于 Pod 数，BPF 查找更快
策略迁移/升级 需重新计算 IP 段，风险较高 Identity 不变，策略无缝迁移

3.2 Endpoint 选择器：基于 Identity 的精准匹配

Cilium 策略使用 endpointSelector 来匹配目标 Endpoint。与 Kubernetes 原生 podSelector 不同，Cilium 的 endpointSelector 直接匹配 Security Identity，而不是 Pod 标签本身。这意味着：

  • 匹配效率更高： BPF 程序直接比较 Identity 数值，无需遍历标签。
  • 支持更丰富的匹配条件： 除了标签，还可以匹配 Namespace、Cluster、Service 等。
  • 支持外部端点： 可以匹配集群外部的 IP 或 DNS 名称，统一策略模型。
最佳实践： 在编写 CiliumNetworkPolicy 时，优先使用 endpointSelector 配合 matchLabels 或 matchExpressions。避免使用 fromEndpoints 中的 IP 段，除非有特殊的外部访问需求。 
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP

3.3 L3/L4/L7 策略模型：分层安全控制

Cilium 策略模型分为三层，每一层解决不同粒度的安全问题。理解这三层模型，是设计精细化策略、避免过度授权的基础。

Cilium 三层策略模型 L3 层：网络层策略（IP/CIDR） 基于源/目的 IP 地址或 CIDR 段进行访问控制 典型场景：允许特定外部 IP 访问集群 API Server 性能：BPF 直接匹配 IP，延迟 < 1μs L4 层：传输层策略（端口/协议） 基于 TCP/UDP/SCTP 端口号及协议类型进行控制 典型场景：只允许 80/443 端口入站，禁止 SSH 性能：BPF 匹配五元组，延迟 < 2μs L7 层：应用层策略（HTTP/gRPC/Kafka/DNS） 基于 HTTP 方法、路径、Header；gRPC 服务名；Kafka Topic 等进行控制 典型场景：只允许 GET /api/v1/*，禁止 POST /admin 性能：需代理解析（Envoy），延迟 < 100μs，但安全粒度最高 策略组合：L3 + L4 + L7 可叠加使用，实现最小权限原则

3.4 策略执行顺序：规则优先级与冲突解决

Cilium 策略的执行顺序遵循 白名单（默认拒绝） 模型，且规则按以下优先级处理：

  1. 默认拒绝： 如果没有显式允许规则，所有流量被拒绝。
  2. L3/L4 规则优先： 基于 Identity 和端口号的规则最先匹配。
  3. L7 规则次之： 在 L3/L4 允许通过后，再检查 L7 应用层规则。
  4. 规则合并： 多个策略作用于同一 Endpoint 时，规则取 并集（只要有一个策略允许，则允许）。
  5. 规则冲突： 如果同一流量同时匹配允许和拒绝规则，拒绝规则优先（安全优先）。
常见陷阱： 当多个 CiliumNetworkPolicy 作用于同一个 Pod 时，如果其中一个策略允许了某个端口，另一个策略拒绝了该端口，最终结果是 拒绝。务必使用 kubectl describe cnp 查看策略状态，避免意外阻断。

3.5 策略执行流程：从 Endpoint 到 BPF 的完整链路

理解策略如何从 YAML 文件转化为 BPF 程序，有助于诊断策略问题和优化性能。

Cilium 策略执行流程 用户提交 YAML Cilium Operator Cilium Agent BPF Map CiliumNetworkPolicy 校验、转换 Identity 生成 BPF 规则 存储规则 数据包到达节点网卡 ↓ BPF 程序在 XDP/TC 钩子处拦截 → 提取源/目的 Identity → 查找 BPF Map 策略 → 允许/拒绝 关键优化点：BPF Map 查找时间复杂度 O(1)，Identity 数量远小于 Pod 数量 策略变更时，仅更新 BPF Map 中的对应条目，无需重启 Agent 或 Pod

3.6 策略调试与验证

在升级或变更策略前，务必使用以下工具验证策略效果：

工具/命令 用途 示例
cilium endpoint list 查看所有 Endpoint 及其 Identity cilium endpoint list | grep my-pod
cilium policy trace 模拟流量，验证策略是否允许/拒绝 cilium policy trace --src-k8s-pod default/frontend --dst-k8s-pod default/backend --dport 8080
cilium monitor 实时监控数据包和策略决策 cilium monitor --type drop
kubectl describe cnp 查看 CiliumNetworkPolicy 状态 kubectl describe cnp allow-frontend-to-backend
升级前必做： 在测试环境使用 cilium policy trace 模拟所有关键业务路径的流量，确保升级后策略不会意外阻断。记录每次 trace 结果，作为升级回退的参考基线。
← 上一章 📖 返回目录 下一章 →