📚 课程目录第3章 Cilium网络策略模型

3. Cilium 网络策略模型：基于身份的安全策略、L3/L4/L7 策略层级、策略与 NetworkPolicy 的关系

Cilium 的网络策略模型彻底改变了 Kubernetes 原生的安全范式。它不再依赖传统的 IP 地址或节点标签，而是引入了一套基于身份（Identity）的零信任安全架构。本章将深入剖析 Cilium 策略模型的三大核心支柱：身份驱动的安全基座、多层级（L3/L4/L7）策略的叠加机制，以及它与标准 Kubernetes NetworkPolicy 的兼容与扩展关系。

3.1 基于身份的安全策略：从 IP 到身份的范式转变

在传统 Kubernetes 网络策略中，安全规则通常依赖于 Pod 的 IP 地址或节点拓扑。然而，在微服务架构中，Pod 是高度动态的，IP 地址频繁变化，导致策略维护成本极高。Cilium 通过 eBPF 实现了基于身份（Identity-Based）的策略模型，将安全决策的锚点从“网络地址”迁移到“工作负载身份”。

  核心概念： Cilium 为每个 Pod 或端点分配一个全局唯一的 24 位安全身份（Security Identity）。这个身份由一组标签（Labels）通过哈希计算得出，例如 app=frontend、env=prod。当 Pod 启动或标签变更时，Cilium 的 Operator 组件会实时更新身份分配，确保策略始终绑定到正确的身份上。

下图展示了 Cilium 如何将 Kubernetes 标签映射为安全身份，并基于此执行网络策略。

最佳实践： 在设计 Cilium 策略时，应优先使用有意义的、稳定的 Kubernetes 标签（如 app、role、tier）来定义身份。避免使用 pod-template-hash 等 Deployment 自动生成的、会随版本迭代变化的标签，以防止策略意外失效。

3.2 L3/L4/L7 策略层级：从网络层到应用层的纵深防御

Cilium 的策略模型是分层且可叠加的。它允许安全团队在同一策略规则中，同时定义网络层（L3）、传输层（L4）和应用层（L7）的约束条件。这种分层模型实现了从“能否通信”到“通信内容是否合规”的精细化控制。

策略层级	控制粒度	典型匹配条件	示例场景
L3 (网络层)	IP 地址 / CIDR	源/目的 IP 范围、节点、集群外端点	允许前端 Pod 访问数据库集群的特定 IP 段
L4 (传输层)	端口 / 协议	TCP/UDP/SCTP 端口号	仅允许 80 和 443 端口访问 Web 服务
L7 (应用层)	HTTP 方法 / 路径 / 头部	HTTP GET/POST, gRPC 方法, Kafka Topic	只允许 `GET /api/v1/books` 请求，拒绝 `DELETE` 操作

下图展示了 Cilium 如何在一个策略规则中叠加 L3、L4 和 L7 的匹配条件，形成纵深防御。

性能注意事项： L7 策略依赖于 Cilium 的代理模式（通常基于 Envoy），这会引入额外的上下文切换和数据拷贝。对于延迟敏感或高吞吐量的应用（如实时流处理、高频交易），建议仅在关键路径上使用 L7 策略，并优先使用 L3/L4 策略进行粗粒度过滤。

3.3 策略与 NetworkPolicy 的关系：兼容、增强与扩展

Cilium 完全兼容标准的 Kubernetes NetworkPolicy API，这意味着现有的 NetworkPolicy 资源可以无缝迁移到 Cilium 环境中。同时，Cilium 通过自定义资源定义（CRD）——CiliumNetworkPolicy 和 CiliumClusterwideNetworkPolicy——提供了远超原生的扩展能力。

下表对比了标准 NetworkPolicy 与 Cilium 扩展策略的关键差异：

特性维度	标准 Kubernetes NetworkPolicy	CiliumNetworkPolicy (CRD)
策略范围	仅支持 Namespace 内	支持 Namespace 内、跨 Namespace、集群范围
身份识别	基于 IP 和标签（有限）	基于 Cilium 安全身份（标签哈希）
L7 支持	不支持	支持 HTTP、gRPC、Kafka、DNS 等协议
集群外通信	不支持（仅 Pod 到 Pod）	支持通过 `toFQDN` 和 `toCIDR` 控制外部访问
策略优先级	无优先级，默认拒绝	支持优先级字段，可精细控制策略生效顺序

以下是一个同时使用标准 NetworkPolicy 和 CiliumNetworkPolicy 的示例，展示如何从兼容逐步过渡到增强。

---
# 标准 NetworkPolicy：允许 frontend 访问 backend 的 80 端口
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 80
      protocol: TCP
---
# CiliumNetworkPolicy：在相同规则上叠加 L7 限制
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-protected-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: '80'
        protocol: TCP
      rules:
        http:
        - method: GET
          path: '/api/v1/items'

迁移策略： 建议采用“双轨并行”策略。首先，使用标准 NetworkPolicy 定义基础的 L3/L4 隔离规则。然后，针对需要深度可见性或精细控制的服务，逐步引入 CiliumNetworkPolicy 来叠加 L7 规则。Cilium 会自动合并两种策略，确保不会产生冲突。

通过这种兼容与扩展的设计，Cilium 既保护了用户在 Kubernetes 原生安全上的投资，又为向零信任、应用感知的安全架构演进提供了平滑的路径。在下一节中，我们将深入探讨如何将这些策略模型落地到具体的控制面组件中。