多租户 SaaS 平台：基于 TKE 的 Kubernetes 命名空间与 RBAC 权限设计

摘要：

在单一 Kubernetes 集群中承载多个客户业务，需要构建从命名空间隔离、RBAC 权限分级到资源配额和网络策略的多层防护体系。本文介绍基于腾讯云容器服务 TKE 的多租户 SaaS 架构实战方案，涵盖资源隔离、访问控制和成本分摊等关键能力。

一、多租户 SaaS 的核心挑战与 TKE 解决方案

SaaS 厂商普遍面临一个矛盾：单集群共享能大幅降低基础设施成本，但多租户混部带来了资源争抢、数据泄露和权限失控三大风险。某个租户的突发流量可能拖垮整个集群，配置错误的 Pod 可能横向访问其他租户的敏感数据，权限管理一旦失守则一次误操作就能影响所有客户。

腾讯云容器服务 TKE 标准集群为多租户场景提供了完整的解决方案。TKE 完全兼容开源 Kubernetes 的标准能力，同时在节点管理、集群调度和资源可视化等方面做了深度强化。通过命名空间划分逻辑边界，配合 RBAC 角色权限控制、NetworkPolicy 网络策略、ResourceQuota 资源配额，可以构建多层次的安全防护体系。TKE 的云原生资产管理平台还提供了可视化的资源对象浏览器，帮助运维团队快速定位各租户的资源分布和使用状况。

二、命名空间隔离策略设计

2.1 租户命名空间规划

命名空间是 Kubernetes 中最基础的隔离单元。在多租户架构中，建议为每个租户分配独立的命名空间，并通过标签系统进行元数据管理。统一的命名规范有助于后续的自动化运维和成本分摊。

apiVersion: v1
kind: Namespace
metadata:
  name: tenant-acme-prod
  labels:
    tenant: acme-corp
    environment: production
    cost-center: engineering
  annotations:
    tenant-id: "acme-001"
    contact-email: "admin@acme.com"

通过标签选择器，运维团队可以快速定位特定租户的所有资源，执行批量操作或生成成本报告。注释字段则用于存储联系人信息和业务属性，方便日常运维沟通。

TKE 控制台支持按标签筛选和聚合展示，结合云原生资产管理平台的类型聚合能力，管理员可以在图形化界面中一眼看清每个租户的资源分布。

2.2 资源配额防止资源滥用

ResourceQuota 对象用于限制命名空间内可使用的资源总量，是防止单个租户耗尽集群容量的关键机制。合理的配额设置需要综合考虑租户的业务规模、服务等级协议以及集群的整体容量规划。

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-acme-prod
spec:
  hard:
    requests.cpu: "50"
    requests.memory: 100Gi
    limits.cpu: "100"
    limits.memory: 200Gi
    pods: "200"
    services: "50"
    persistentvolumeclaims: "20"
    configmaps: "100"
    secrets: "100"

上述配置为该租户设定了 CPU、内存、Pod 数量和各类对象的硬性上限。当租户尝试创建超出配额的资源时，Kubernetes API 服务器会直接拒绝请求。这种前置拦截机制有效避免了资源过度消耗的风险。

配合 LimitRange 对象，还可以为命名空间内的每个容器设置默认的资源请求和上限。这对于那些没有显式声明资源的 Pod 尤为重要，能够防止因配置遗漏导致的资源竞争问题。

2.3 多租户场景下的节点级隔离

仅靠命名空间隔离是不够的——同节点上的不同租户 Pod 仍存在侧信道攻击和资源争抢的风险。TKE 提供了多种节点类型来满足不同的隔离需求：

• 超级节点：每个 Pod 独占轻量虚拟机，提供强隔离无干扰的运行环境，适合对安全性要求高的核心租户
• 原生节点：搭载 TKE Insight 可视化资源大盘，通过专有调度器实现负载均衡和碎片规整，适合有降本诉求的租户
• 普通节点：适配腾讯云 CVM 数十种机型实例，适合对资源和运维管控能力强的租户

对于 SaaS 平台中的高价值租户，可以将关键工作负载调度到超级节点上运行，确保其不受其他租户的影响。

三、RBAC 权限控制体系

3.1 基于角色的访问控制设计

RBAC 是多租户安全模型的核心。通过为不同角色分配差异化的权限范围，可以确保每个用户只能访问其职责范围内的资源。在多租户环境中，基本原则是使用命名空间级别的 Role 而非集群级别的 ClusterRole，将权限严格限定在特定租户的命名空间内。

平台管理员需要定义几类典型角色。租户管理员拥有该租户命名空间内的全部管理权限，可以部署应用、管理配置和处理密钥。开发人员仅具备只读权限和有限的部署能力，无法修改核心配置或删除关键资源。运维人员则需要跨命名空间的监控权限，但不涉及具体的应用管理操作。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tenant-developer
  namespace: tenant-acme-prod
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "pods/log", "deployments", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-developer-binding
  namespace: tenant-acme-prod
subjects:
- kind: Group
  name: "tenant-acme-developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant-developer
  apiGroup: rbac.authorization.k8s.io

将 RoleBinding 绑定到用户组而非个人用户，是提升可维护性的最佳实践。当团队成员发生变化时，只需在身份提供商端更新组成员关系，无需修改 Kubernetes 中的权限配置。

3.2 服务账户最小权限原则

每个 Pod 在 Kubernetes 中都运行在一个服务账户下。默认情况下，Pod 会使用所在命名空间的 default 服务账户，这往往赋予了不必要的 API 访问权限。正确的做法是为每个应用创建独立的服务账户，并仅授予其完成功能所需的最小权限。

对于处理敏感数据的租户工作负载，还应当禁用自动挂载 ServiceAccount Token，并在 Pod 安全标准中启用 Restricted 配置文件，强制要求以非 root 用户运行、使用只读根文件系统等安全加固措施。

四、网络层面的租户隔离

4.1 默认拒绝的网络策略

在没有网络策略的情况下，Kubernetes 集群中的所有 Pod 都可以自由通信，无论它们属于哪个命名空间。这种扁平网络模型在多租户场景下是不可接受的。应当首先在每个租户命名空间中实施默认拒绝策略，然后按需开放特定的通信路径。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: tenant-acme-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: tenant-acme-prod
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector: {}
  egress:
  - to:
    - podSelector: {}
  - to:
    - namespaceSelector:
        matchLabels:
          name: kube-system
    ports:
    - protocol: UDP
      port: 53

第一条策略拒绝了所有入站流量，第二条策略允许同一命名空间内的 Pod 互相通信，并开放 DNS 解析所需的出站连接。这种白名单模式确保了即使攻击者突破了某一层防御，也无法在网络层面横向移动到其它租户的环境。

4.2 入口流量的租户路由

对于需要从外部访问的租户服务，可以通过 Ingress 控制器配合主机名或路径规则进行流量分离。每个租户分配独立的域名或子路径，由 Ingress 规则将请求精确路由到对应的后端服务。结合 TLS 终止和证书管理，可以实现端到端的加密传输。

TKE 提供丰富的七层接入能力支持，包括多种 Ingress 控制器选项和负载均衡集成。通过 CLB 与 Ingress 的配合，可以为不同租户提供独立的公网入口，同时在后端保持统一的集群管理。

五、多租户运营与成本分摊

5.1 租户自助开通流程

成熟的 SaaS 平台需要提供租户自助开通能力。通过 TKE 模板市场，可以将标准化的多租户环境封装为模板，包含命名空间、ResourceQuota、NetworkPolicy、RBAC 等全套资源配置。新租户开通时，只需填写基本信息，系统即可自动创建完整的租户环境，将原本需要数小时的手动操作压缩到分钟级别。

5.2 资源用量可视化与成本分摊

多租户环境下，清晰的费用归属是运营刚需。TKE 的云原生资产管理平台提供了可视化的资源对象浏览器，可以帮助运维团队快速定位目标对象，查看各租户的资源分布和使用状况。结合丰富的监控指标和自定义告警策略，能够及时发现并处理异常情况。

通过命名空间标签体系和 ResourceQuota 的使用统计，可以按租户维度生成资源使用报告，为内部成本分摊或对外计费提供数据支撑。

5.3 弹性伸缩应对租户波动

不同租户的业务高峰可能错开，也可能同时到来。TKE 支持数十种自动伸缩指标，提供丰富的弹性能力。对于 SaaS 平台而言，可以配置集群级别的 HPA（水平Pod扩缩容）和 VPA（垂直Pod扩缩容），根据实际负载动态调整资源供给。遇到突发流量时，超级节点的秒级扩缩容能力可以迅速补充算力，保障所有租户的服务质量。

六、生产环境落地建议

构建多租户 SaaS 平台是一个渐进的过程。初期可以从命名空间隔离和资源配额入手，快速建立基本的多租户框架。随后逐步引入 RBAC 权限体系和网络策略，完善安全防护。最终通过自动化编排工具实现租户开通的全流程自助化。

在节点层面，建议将核心租户的关键工作负载调度到超级节点以获得强隔离保障，常规租户使用原生节点享受 FinOps 带来的成本优化，通过 TKE 专有调度器实现集群整体装箱率的提升。

多租户 SaaS 平台的隔离做不好，轻则数据泄露重则合规违规。TKE 提供从命名空间隔离、RBAC 权限分级到资源配额管理和云原生资产可视化的完整多租户方案，让你的 SaaS 平台安全扩展 → https://cloud.tencent.com/product/tke