📚 课程目录第1章多租户隔离概述

1. 多租户隔离概述

多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例或基础设施集群同时服务于多个独立用户群体（即“租户”）。在云原生语境下，每个租户通常对应一个团队、一个项目、一个业务线或一个外部客户，租户之间在逻辑上完全隔离，但在物理上共享同一套 Kubernetes 集群资源。

多租户的核心目标是在共享资源的同时，确保每个租户的数据安全、资源公平性和操作独立性。租户不应感知到其他租户的存在，也不应能越权访问或影响其他租户的工作负载。

  关键特征： 隔离性（Isolation） > 可管理性（Manageability） > 成本效率（Cost Efficiency）

Kubernetes 原生设计并未内置“租户”概念，其 RBAC、NetworkPolicy、ResourceQuota 等机制虽然提供了隔离基础，但在真实多租户场景中仍面临以下核心挑战：

命名空间隔离的局限性：命名空间（Namespace）是 Kubernetes 最常用的逻辑隔离边界，但 ClusterRole、ClusterRoleBinding、CustomResourceDefinition（CRD）等集群级资源天然跨命名空间，一个租户的误操作可能影响全局。
网络策略管理复杂：NetworkPolicy 只能控制 Pod 间流量，无法限制节点端口、HostNetwork 或 Service 外部访问；大规模租户下策略数量激增，维护成本高。
资源配额与公平调度：ResourceQuota 和 LimitRange 只能按命名空间设置，无法实现跨命名空间的租户级资源池；多个命名空间属于同一租户时，资源分配难以统一管控。
审计与合规追溯：Kubernetes 审计日志默认记录 API 请求，但缺乏租户维度的聚合视图；当多个租户共享同一集群时，定位“谁在什么时间对哪个资源做了什么操作”变得困难。
Helm 部署的权限扩散：Helm 在安装/升级 Chart 时，Tiller（v2）或 Helm Controller（v3）需要较高的 RBAC 权限；若权限边界不清晰，租户可能通过 Helm 操作越权访问集群级资源。

常见误区： 仅靠命名空间 + RBAC 就认为实现了多租户隔离。实际上，CRD、ValidatingWebhookConfiguration、PriorityClass 等集群级资源仍可能成为租户间的“后门”。

Helm 作为 Kubernetes 的包管理器，在多租户环境中扮演着双刃剑的角色：

正面角色：Helm Chart 将一组相关的 Kubernetes 资源（Deployment、Service、ConfigMap、RBAC 等）打包为可重复部署的单元，配合模板引擎和 Values 注入，可以快速为每个租户生成隔离的命名空间和资源配置，极大提升多租户环境下的部署效率。
负面风险：Helm 的安装/升级操作需要较高的 RBAC 权限（尤其是涉及 CRD、ClusterRole、ValidatingWebhookConfiguration 等集群级资源时）。若权限边界未严格约束，租户可能通过 Helm 越权创建或修改集群级对象，导致隔离失效。

最佳实践： 在多租户集群中，Helm 应配合 权限边界模板 使用：每个租户的 Helm 操作仅允许在其所属命名空间内创建资源，禁止操作集群级资源。通过 OPA/Gatekeeper 或 Kyverno 策略引擎，可以在 Admission 阶段拦截越权的 Helm 部署。

在实际落地中，多租户隔离通常分为以下四个层次，Helm 在每个层次中都有对应的介入点：

隔离层次	实现手段	Helm 介入点
身份与认证	OIDC、ServiceAccount、kubeconfig 绑定租户标识	Chart 中预置 ServiceAccount 模板，绑定租户 Role
授权与 RBAC	Role、RoleBinding、ClusterRole（受限）	Helm 模板生成租户级 Role，禁止 ClusterRole 绑定
资源与配额	ResourceQuota、LimitRange、PriorityClass	Values 传入租户配额参数，Chart 自动生成 Quota 对象
网络与安全	NetworkPolicy、PodSecurityPolicy（PSP）/ Pod Security Admission	Chart 模板生成租户隔离的 NetworkPolicy，限制入站/出站

  核心原则： Helm Chart 模板蓝图必须将“租户标识”作为第一类输入参数，所有生成的资源都应携带租户标签（如 tenant: <tenant-id>），以便审计链路进行租户维度的聚合与追溯。