3. 租户隔离蓝图设计：基于 CiliumNetworkPolicy 的租户隔离模型、租户标识（Label/ServiceAccount）设计

在 Kubernetes 多租户环境中，网络隔离是保障租户安全的第一道防线。Cilium 通过 CiliumNetworkPolicy (CNP) 提供了比传统 NetworkPolicy 更精细、更高效的隔离能力。本章将深入设计基于 CNP 的租户隔离模型，并明确租户标识（Label / ServiceAccount）的设计策略。

3.1 租户隔离模型架构

本课程采用的租户隔离模型遵循 “命名空间 + 标识 + 策略” 三层架构。每个租户拥有独立的命名空间，通过 ServiceAccount 和自定义 Label 进行身份标识，再通过 CiliumNetworkPolicy 实现东西向与南北向的流量控制。

3.2 租户标识设计：Label 与 ServiceAccount

租户标识是策略匹配的基础。CiliumNetworkPolicy 支持基于 Label 和 ServiceAccount 两种方式进行身份选择。本设计采用 “ServiceAccount 为主，Label 为辅” 的策略。

3.3 CiliumNetworkPolicy 隔离策略设计

基于上述标识设计，我们定义三类核心策略：

1. 基础拒绝策略（Default Deny）：在每个租户命名空间内部署，拒绝所有入站和出站流量，除非被显式允许。
2. 同租户允许策略：允许相同 tenant Label 的 Pod 之间通信。
3. 跨租户白名单策略：在需要时，显式允许特定 ServiceAccount 或 Label 的跨租户访问。

3.4 策略示例：同租户内部通信

以下策略允许租户 A 命名空间内所有具有 tenant=tenant-a Label 的 Pod 相互通信：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-same-tenant-a
  namespace: ns-tenant-a
spec:
  endpointSelector:
    matchLabels:
      tenant: tenant-a
  ingress:
    - fromEndpoints:
        - matchLabels:
            tenant: tenant-a
  egress:
    - toEndpoints:
        - matchLabels:
            tenant: tenant-a

3.5 策略示例：跨租户白名单通信

当租户 A 的 backend 服务需要访问租户 B 的 db 服务时，需要在租户 B 的命名空间中创建入站策略：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-from-tenant-a-backend
  namespace: ns-tenant-b
spec:
  endpointSelector:
    matchLabels:
      app: db
  ingress:
    - fromEndpoints:
        - matchLabels:
            tenant: tenant-a
            app: backend

3.6 标识设计对比总结