📚 课程目录第3章多租户隔离模型

3. 多租户隔离模型：基于Cluster的硬隔离、基于Namespace的软隔离、基于CiliumNetworkPolicy的微隔离

在多租户 Kubernetes 集群中，隔离模型的选择直接决定了租户之间的安全边界、资源管控粒度以及运维复杂度。Cilium 基于 eBPF 的数据路径为这三种隔离模型提供了统一的实现底座。本章将系统阐述三种隔离模型的设计原理、适用场景与 Cilium 的落地方式。

3.1 三种隔离模型总览

下表从隔离强度、资源边界、网络策略作用域、典型场景四个维度对比三种模型：

隔离模型	隔离强度	资源边界	网络策略作用域	典型场景
Cluster 硬隔离	物理/虚拟集群级	独立集群	集群边界天然阻断	金融核心、合规敏感、完全独立租户
Namespace 软隔离	逻辑命名空间级	共享集群	默认全通，需 NetworkPolicy 加固	开发/测试环境、部门级隔离
CiliumNetworkPolicy 微隔离	Pod/Service 级	共享集群	基于标签的细粒度 L3-L7 策略	零信任、东西向流量管控、多租户混合部署

关键认知：三种模型并非互斥关系。在实际生产环境中，通常以 Cluster 硬隔离作为第一道防线，Namespace 软隔离作为逻辑分区，CiliumNetworkPolicy 微隔离作为精细化访问控制手段，形成纵深防御体系。

3.2 基于 Cluster 的硬隔离

硬隔离是最彻底的隔离方式，每个租户拥有独立的 Kubernetes 集群。集群之间不存在任何网络、存储或 API 层面的共享。

3.2.1 架构特征

完全独立控制面：每个租户拥有独立的 API Server、etcd、Controller Manager。
数据面隔离：节点、CNI、Service Mesh 均为独立部署，无跨集群流量。
管理边界清晰：租户管理员拥有集群 root 权限，可自定义任何资源。

3.2.2 Cilium 在硬隔离中的角色

在 Cluster 硬隔离模式下，Cilium 在每个集群内独立运行。Cilium Agent 仅管理本集群的 eBPF 程序与端点。跨集群通信需通过 Gateway API 或 Service Mesh 的隧道网关实现，Cilium Cluster Mesh 可用于跨集群服务发现，但默认不打通租户边界。

  适用建议：当租户需要运行自定义 kubelet 参数、使用 HostNetwork、或存在强合规审计要求时，优先选择 Cluster 硬隔离。代价是资源利用率较低，管理成本随租户数量线性增长。

3.3 基于 Namespace 的软隔离

软隔离在共享集群内通过 Kubernetes Namespace 实现逻辑分区。每个租户拥有独立的 Namespace 集合，但共享同一个控制面和数据面。

3.3.1 隔离边界

资源配额：通过 ResourceQuota 限制每个 Namespace 的 CPU、内存、PVC 数量。
RBAC：通过 RoleBinding 限定租户仅能操作本 Namespace 内的资源。
网络策略：默认所有 Pod 互通，需显式创建 NetworkPolicy 进行隔离。

3.3.2 软隔离的局限性

Namespace 软隔离无法阻止以下风险：

恶意 Pod 通过 NodePort 或 HostNetwork 绕过网络策略。
共享节点上的资源争抢（CPU 缓存、网络带宽）。
集群级资源的误操作（如删除 CRD、修改 Webhook）。

注意：仅依赖 Namespace 软隔离无法满足生产级多租户安全要求。必须配合 NetworkPolicy 和 Pod Security Admission 进行加固。

3.4 基于 CiliumNetworkPolicy 的微隔离

微隔离是 Cilium 的核心能力，通过 eBPF 在数据面实现 Pod 级别的 L3-L7 网络策略，无需修改应用代码或引入 Sidecar。

3.4.1 策略模型

CiliumNetworkPolicy 使用 Kubernetes 标签选择器定义流量规则，支持以下维度：

策略维度	描述	示例
身份（Identity）	基于 Pod 标签自动分配安全身份	`app=frontend`
L3/L4	IP + 端口 / CIDR	`toPorts: 8080`
L7	HTTP 方法、路径、gRPC 方法	`http.path: "/api/v1"`
DNS	基于域名解析的访问控制	`toFQDNs: *.internal`

3.4.2 微隔离实现多租户

在共享集群中，通过 CiliumNetworkPolicy 可以实现租户间的零信任隔离：

租户内全通：允许同一租户 Namespace 内的所有 Pod 互通。
租户间默认拒绝：禁止跨 Namespace 的任意流量，除非显式授权。
共享服务授权：允许所有租户访问 DNS、监控、日志等基础设施 Pod。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-a
spec:
  endpointSelector:
    matchLabels:
      tenant: a
  ingress:
    - fromEndpoints:
        - matchLabels:
            tenant: a
  egress:
    - toEndpoints:
        - matchLabels:
            tenant: a
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP

最佳实践：使用 CiliumClusterwideNetworkPolicy 定义全局默认拒绝策略，再通过 Namespace 级别的 CiliumNetworkPolicy 开放租户内通信。这种分层策略设计可避免策略遗漏。

3.5 三种隔离模型的协同架构

下图展示了三种隔离模型在 Cilium 驱动下的协同工作方式：

3.6 隔离模型选择决策树

在实际项目中，可根据以下条件快速选择隔离模型：

租户是否需要独立控制面？ → 是 → Cluster 硬隔离
租户数量是否超过 50？ → 是 → 考虑 Cluster 硬隔离 + 自动化集群管理
租户间是否存在互信？ → 否 → 必须启用 CiliumNetworkPolicy 微隔离
是否需要 L7 协议管控？ → 是 → 使用 CiliumNetworkPolicy L7 规则
仅需资源配额和 RBAC？ → 是 → Namespace 软隔离 即可满足

  生产建议：推荐采用“Cluster 硬隔离 + Namespace 软隔离 + CiliumNetworkPolicy 微隔离”三层叠加模式。例如：金融租户使用独立集群（硬隔离），内部开发团队使用 Namespace 分区（软隔离），关键服务间通过 CiliumNetworkPolicy 实施零信任策略（微隔离）。这种组合既能满足合规要求，又能最大化资源利用率。

3.7 本章小结

Cluster 硬隔离提供最强安全边界，适用于高合规、高敏感场景，但资源利用率低。
Namespace 软隔离实现逻辑分区，管理成本低，但需配合网络策略弥补安全短板。
CiliumNetworkPolicy 微隔离在共享集群中实现 Pod 级零信任，支持 L3-L7 精细化管控。
三种模型可组合使用，形成纵深防御体系，Cilium 的 eBPF 技术为所有模型提供高性能数据面支持。