3. 多租户隔离架构蓝图总览：控制面隔离、数据面隔离、网络隔离、存储隔离、审计隔离的整体架构设计

多租户隔离集群的核心在于将共享基础设施的“风险”与“干扰”降至最低。本章从架构蓝图出发，系统阐述五大隔离维度的设计原则与实现路径：控制面隔离、数据面隔离、网络隔离、存储隔离以及审计隔离。这五个维度共同构成了一个纵深防御的租户隔离体系，确保任何一个租户的异常行为不会扩散到其他租户或集群控制面。

3.1 五大隔离维度总览

下表从隔离目标、核心机制、关键风险三个角度，快速建立对五大维度的整体认知：

3.2 整体架构蓝图（SVG）

下图展示了多租户隔离集群的完整架构蓝图，清晰呈现控制面、数据面、网络、存储、审计五个隔离层在集群中的位置与交互关系：

3.3 控制面隔离：第一道防线

控制面隔离的目标是防止租户操作影响集群核心组件。在共享控制面模式下，所有租户共享同一个 API Server、Scheduler 和 Controller Manager，因此必须通过以下机制实现隔离：

• 命名空间（Namespace）：每个租户分配独立 Namespace，作为资源隔离的基本单元。
• RBAC（基于角色的访问控制）：为每个租户创建专用 ServiceAccount 和 Role/ClusterRole，严格限制其 API 操作范围。
• 准入控制（Admission Webhook）：通过 MutatingWebhook 和 ValidatingWebhook 强制注入租户标签、校验资源配额、阻止特权操作。
• 资源配额（ResourceQuota）：限制每个租户的 CPU、内存、存储、Pod 数量等资源上限，防止资源耗尽攻击。
• 优先级与抢占（PriorityClass）：为不同租户设置不同优先级，避免高优租户无限抢占低优租户资源。

3.4 数据面隔离：工作负载安全

数据面隔离关注的是租户工作负载（Pod/Container）之间的运行时隔离。即使控制面隔离被绕过，数据面隔离仍能阻止恶意容器影响其他租户。核心机制包括：

• Pod Security Standards（PSS）：强制应用 Pod 安全策略（Privileged / Baseline / Restricted），禁止特权容器、hostNetwork、hostPID 等危险配置。
• 运行时类（RuntimeClass）：为高安全租户分配沙箱化运行时（如 gVisor、Kata Containers），提供内核级隔离。
• 节点亲和性与污点（Taint/Toleration）：将不同租户的 Pod 调度到不同节点池，实现物理/虚拟节点级隔离。
• 资源限制（LimitRange）：为每个 Namespace 设置默认的 CPU/内存请求与限制，防止单个 Pod 耗尽节点资源。
• Sidecar 注入策略：通过 Istio/Linkerd 的 Sidecar 注入，实现租户级流量管控与 mTLS 加密。

3.5 网络隔离：防止横向移动

网络隔离的目标是限制租户间的网络通信，防止攻击者从一个租户的 Pod 横向移动到另一个租户的 Pod。实现网络隔离的三大支柱：

网络隔离的默认策略应为“拒绝所有跨命名空间流量”，然后按需开放。以下是一个典型的租户隔离 NetworkPolicy 示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          tenant: tenant-a
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          tenant: tenant-a
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    - ports:
      - port: 53
        protocol: UDP

3.6 存储隔离：数据安全与持久化

存储隔离确保租户的数据卷不会被其他租户访问或篡改。在多租户集群中，存储隔离需要从以下维度保障：

• StorageClass 租户绑定：为每个租户分配专用的 StorageClass，或通过准入控制强制 PVC 只能使用特定 StorageClass。
• PVC 命名空间隔离：PVC 是命名空间级别的资源，天然隔离。但需注意：某些 CSI 驱动（如 NFS）可能允许跨命名空间挂载，需通过卷访问模式（AccessModes）限制。
• 卷加密：使用 CSI 加密功能（如 LUKS）或 KMS 集成，确保即使存储后端被攻破，数据仍不可读。
• 回收策略：建议将 PVC 的回收策略设置为 Retain，防止租户删除 PVC 后数据被自动清理，导致其他租户意外获取残留数据。
• 快照与克隆隔离：VolumeSnapshot 和 VolumeClone 操作必须限制在同一 Namespace 内，禁止跨租户快照共享。

3.7 审计隔离：可追溯性与合规

审计隔离是五大隔离维度中的“最后一道防线”，它不直接阻止攻击，但提供完整的操作记录，用于事后追溯、合规审计和异常检测。审计隔离的设计要点：

• 租户级审计策略：为每个租户定义独立的审计策略（Audit Policy），记录其所有 API 操作（包括读操作）。
• 日志路由与标签：使用 Fluentd/Logstash 将审计日志按租户标签（如 tenant-id）路由到独立的日志存储桶或索引。
• 日志存储隔离：每个租户的审计日志存储在独立的 S3 桶、Elasticsearch 索引或日志流中，防止日志泄露。
• 审计告警：基于租户级审计日志设置告警规则（如“连续 5 次 RBAC 拒绝”或“创建特权 Pod”），实现实时安全响应。

以下是一个租户级审计策略的配置片段：

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  users: ["system:serviceaccount:tenant-a:*"]
  resources:
  - group: ""
    resources: ["pods", "secrets", "configmaps"]
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings"]
- level: Metadata
  users: ["system:serviceaccount:tenant-a:*"]
  resources:
  - group: ""
    resources: ["events", "namespaces"]

3.8 五大隔离维度的协同关系

五大隔离维度并非孤立工作，而是形成纵深防御体系。下图展示了它们之间的协同关系：