Cilium网络策略在控制面授权测试中的工程实践 - 第4节

4.1 CiliumNetworkPolicy 策略模型总览

CiliumNetworkPolicy 是 Cilium 提供的 Kubernetes 原生网络策略 CRD，其核心设计理念是 基于身份（Identity）而非 IP 地址 的零信任网络控制。与传统 Kubernetes NetworkPolicy 相比，CiliumNetworkPolicy 在 L3/L4 基础上扩展了 L7 应用层控制能力，并引入了灵活的 Endpoint 选择器机制。

关键认知： Cilium 网络策略的三大支柱——L3/L4 网络层（IP+端口）、L7 应用层（HTTP/gRPC/Kafka 等协议字段）、Endpoint 选择器（基于标签的身份匹配）——共同构成了控制面授权测试的原子能力单元。
CiliumNetworkPolicy 三层策略模型 L3/L4 网络层策略 基于 IP 地址、CIDR、端口号、协议（TCP/UDP/SCTP）的访问控制 示例：允许 10.0.0.0/8 访问 80/TCP 端口 L7 应用层策略 基于 HTTP 方法/路径/Header、gRPC 服务/方法、Kafka Topic 等协议字段 示例：允许 GET /api/v1/*，拒绝 DELETE 操作 Endpoint 选择器与 Identity 层 基于 Kubernetes 标签、ServiceAccount、ClusterRole 的身份匹配 示例：app=frontend 标签的 Pod 可以访问 app=backend 的 Pod 基础网络控制 应用层语义控制 身份驱动匹配

4.2 L3/L4 策略：网络层访问控制

L3/L4 策略是 CiliumNetworkPolicy 的基础层，负责控制基于 IP 地址、端口号和传输层协议的流量。在控制面授权测试中，L3/L4 策略用于验证网络边界的可达性约束。

4.2.1 核心字段与语法

字段 类型 说明 测试关注点
fromCIDR []string 允许来自指定 CIDR 的入站流量 CIDR 聚合、重叠、边界值
toCIDR []string 允许到指定 CIDR 的出站流量 出站规则对控制面组件的限制
fromEndpoints []EndpointSelector 允许来自匹配标签的 Endpoint 的流量 标签匹配逻辑、空选择器行为
toPorts []PortRule 指定允许的目标端口和协议 端口范围、协议类型、端口别名
测试要点： 在控制面授权测试中，L3/L4 策略的 fromEndpoints 与 toPorts 组合是最常见的测试对象。需要验证当源 Endpoint 标签匹配但目标端口不在允许范围内时，流量是否被正确拒绝。

4.2.2 L3/L4 策略示例

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l3l4-control-plane
  namespace: kube-system
spec:
  endpointSelector:
    matchLabels:
      k8s-app: kube-apiserver
  ingress:
  - fromEndpoints:
    - matchLabels:
        k8s-app: kube-controller-manager
    toPorts:
    - ports:
      - port: "6443"
        protocol: TCP
  egress:
  - toCIDR:
    - 10.96.0.0/12
    toPorts:
    - ports:
      - port: "2379"
        protocol: TCP

上述策略允许 kube-controller-manager 标签的 Pod 访问 kube-apiserver 的 6443/TCP 端口，同时允许 API Server 出站到 etcd 集群的 2379/TCP 端口。

4.3 L7 策略：应用层语义控制

L7 策略是 Cilium 区别于传统 Kubernetes NetworkPolicy 的核心能力。它基于 eBPF 的代理（Envoy）实现，能够解析 HTTP/1.x、HTTP/2、gRPC、Kafka 等应用层协议，实现细粒度的请求级控制。

4.3.1 支持的协议与匹配规则

协议 匹配字段 典型测试场景
HTTP method, path, headers, host REST API 的 GET/POST/DELETE 权限分离
gRPC service, method 微服务间 gRPC 调用的服务级授权
Kafka topic, clientID, 消息队列的生产者/消费者权限控制
DNS matchName, matchPattern 控制面组件 DNS 解析的域名白名单

4.3.2 L7 HTTP 策略示例

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: l7-http-api
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/users/.*"
        - method: POST
          path: "/api/v1/orders"
          headers:
          - "X-Request-Source: web"
测试陷阱： L7 策略依赖 Envoy 代理进行协议解析。如果流量未经过代理（例如使用原始 TCP 连接绕过 HTTP 解析），L7 规则将不会生效。在控制面授权测试中，必须验证 L7 策略的 回退行为——当代理不可用时，流量是被允许还是拒绝。

4.4 Endpoint 选择器：身份匹配的核心机制

Endpoint 选择器是 CiliumNetworkPolicy 中连接策略与工作负载的桥梁。它基于 Kubernetes 标签选择器语义，但扩展了更丰富的匹配操作符。

4.4.1 选择器类型与匹配逻辑

选择器类型 YAML 字段 匹配行为 测试用例
精确匹配 matchLabels 所有指定标签必须完全匹配 单标签、多标签组合
表达式匹配 matchExpressions 支持 In/NotIn/Exists/DoesNotExist 操作符 集合运算、存在性判断
命名空间选择 namespaceSelector 匹配特定命名空间下的 Endpoint 跨命名空间访问控制
ServiceAccount 选择 serviceAccountSelector 匹配特定 ServiceAccount 的 Pod 基于身份的细粒度授权

4.4.2 选择器组合示例

spec:
  endpointSelector:
    matchLabels:
      app: backend
      version: v2
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
      matchExpressions:
      - key: "tier"
        operator: In
        values: ["web", "mobile"]
    - namespaceSelector:
        matchLabels:
          purpose: production
      serviceAccountSelector:
        matchLabels:
          role: api-consumer

上述规则表示：只有同时满足 app=frontend 且 tier 为 web 或 mobile 的 Pod，或者来自 purpose=production 命名空间且 ServiceAccount 标签为 role=api-consumer 的 Pod，才能访问 app=backend, version=v2 的 Pod。

4.5 Identity 概念：从 IP 到身份的范式转换

Identity（身份）是 Cilium 安全模型的基石。传统网络策略基于 IP 地址进行访问控制，而 Cilium 将每个 Endpoint（Pod、外部节点）分配一个全局唯一的数字身份标识，策略引擎基于身份而非 IP 进行决策。

Identity 身份分配与策略决策流程 Pod 创建 标签: app=frontend SA: frontend-sa Cilium Identity 分配 标签哈希 → 数字 ID Identity: 12345 策略引擎决策 检查 Identity 12345 匹配策略规则 → 允许/拒绝 不依赖 IP 地址变化 Identity 的核心优势 1. IP 无关性：Pod 重启或迁移导致 IP 变化时，Identity 保持不变，策略无需更新。 2. 标签驱动：Identity 由 Pod 的标签组合（含 ServiceAccount）计算哈希生成，相同标签的 Pod 共享同一 Identity。 3. 规模化性能：BPF Map 中存储的是数字 ID 而非字符串标签，查找效率为 O(1)。 4. 安全隔离：即使攻击者伪造 IP 地址，也无法获得未授权的 Identity，天然防御 ARP 欺骗。 5. 测试可预测性：控制面授权测试中，只需关注标签组合与 Identity 的映射关系，无需关心底层网络拓扑。

4.5.1 Identity 的生命周期

  1. 分配阶段： 当 Pod 启动时，Cilium Agent 读取其标签和 ServiceAccount，计算 SHA256 哈希，向 Cilium Operator 请求分配全局唯一的数字 Identity。
  2. 缓存阶段： Identity 被缓存在本地 BPF Map 中，后续所有策略决策直接基于数字 ID 进行，避免重复计算。
  3. 回收阶段： 当 Pod 被删除或标签变更时，Identity 进入 graceful period（默认 15 分钟），确保正在进行的连接不会中断。
测试关键点： Identity 的 优雅回收期 是控制面授权测试中容易忽略的环节。测试用例应验证：当 Pod 标签变更后，旧 Identity 是否在回收期内仍然有效？新 Identity 何时生效？这直接影响授权策略的实时性验证。

4.6 三层策略的协同工作与测试矩阵

在实际控制面授权测试中，L3/L4、L7 和 Endpoint 选择器三层策略是协同工作的。一个完整的策略规则通常包含：谁（Endpoint 选择器） + 能访问什么（L3/L4 端口） + 能做什么操作（L7 规则）。

4.6.1 策略组合测试矩阵

测试场景 Endpoint 选择器 L3/L4 规则 L7 规则 预期结果
基础网络可达 匹配 端口允许 无 允许
端口拒绝 匹配 端口拒绝 无 拒绝
L7 方法限制 匹配 端口允许 仅允许 GET GET 允许，POST 拒绝
选择器不匹配 不匹配 端口允许 无 拒绝
L7 代理绕过 匹配 端口允许 HTTP 规则 原始 TCP 连接可能绕过

4.6.2 策略优先级与冲突解决

CiliumNetworkPolicy 遵循 白名单（默认拒绝） 模型。当多条策略作用于同一 Endpoint 时，遵循以下规则：

  • 同一方向（ingress/egress）：多条策略的规则取 并集，即只要有一条策略允许，流量就被允许。
  • 不同方向：ingress 和 egress 独立评估，互不影响。
  • L3/L4 与 L7 冲突：L3/L4 规则优先于 L7 规则。如果 L3/L4 拒绝，即使 L7 允许，流量也会被拒绝。
测试陷阱： 当多个 CiliumNetworkPolicy 应用于同一 Endpoint 时，并集规则 可能导致意外的权限放大。例如，策略 A 允许访问 80 端口，策略 B 允许访问 443 端口，最终效果是允许访问 80 和 443 两个端口。在控制面授权测试中，必须验证策略组合后的实际权限边界是否符合最小权限原则。

4.7 本章小结

本章深入剖析了 CiliumNetworkPolicy 的三大核心概念：

  • L3/L4 策略 提供基础的 IP+端口访问控制，是网络安全的基石。
  • L7 策略 实现应用层语义的细粒度授权，是零信任架构的关键能力。
  • Endpoint 选择器与 Identity 构成了身份驱动的安全模型，彻底摆脱了对 IP 地址的依赖。
← 上一章 📖 返回目录 下一章 →