1. 多租户概念与 K8s：多租户的定义、K8s 多租户模型概述、为什么需要自动化 RBAC

1.1 多租户的定义与核心目标

多租户（Multi-Tenancy）是一种软件架构模式，允许单个软件实例为多个独立的用户群体（租户）提供服务，同时确保每个租户的数据、配置、资源和访问权限彼此隔离。在 Kubernetes 语境下，租户通常对应一个团队、项目、业务线或环境（如开发、测试、预发布）。

多租户的核心目标可归纳为以下三点：

  • 隔离性（Isolation）：租户 A 的 Pod、ConfigMap、Secret 不会被租户 B 意外或恶意访问。
  • 资源配额（Resource Quota）：每个租户只能使用分配给它的 CPU、内存、存储上限，防止“吵闹邻居”效应。
  • 权限边界（Permission Boundary）：租户内的用户只能操作本租户范围内的资源，无法越权查看或修改其他租户的资源。
💡 关键区分：多租户 ≠ 多集群。多租户是在同一集群内通过逻辑隔离实现资源复用；多集群则是物理隔离，管理成本更高。

1.2 K8s 多租户模型概述

Kubernetes 原生并未提供“租户”这一抽象概念，但可以通过以下原生资源组合构建多租户模型：

K8s 资源 在多租户模型中的作用 隔离粒度
Namespace 作为租户的基本边界，将资源分组到虚拟集群中 逻辑隔离
RBAC（Role / ClusterRole / RoleBinding / ClusterRoleBinding） 定义谁（User/ServiceAccount）能对哪些资源（Resource）执行什么操作（Verb） 细粒度权限
ResourceQuota 限制租户的 CPU、内存、PVC 数量等总用量 资源上限
NetworkPolicy 控制 Pod 之间的网络流量，实现租户网络隔离 网络隔离
LimitRange 设置 Pod/Container 的默认资源请求与限制 资源约束

常见的 K8s 多租户模型分为三种：

  1. 命名空间即租户（Namespace-as-a-Tenant）：每个租户独占一个 Namespace，适合中小规模团队。
  2. 集群即租户（Cluster-as-a-Tenant）：每个租户拥有独立集群，隔离最强但管理成本最高。
  3. 虚拟集群（Virtual Cluster）：通过 vCluster 或 Kiosk 等工具在单个集群内模拟多个控制面，兼顾隔离与效率。
K8s 多租户模型对比 K8s 多租户模型对比 Namespace 即租户 租户 A → Namespace A 租户 B → Namespace B 共享集群控制面 RBAC + Quota 隔离 ✅ 成本低，管理简单 ⚠️ 隔离较弱 集群 即租户 租户 A → 集群 A 租户 B → 集群 B 完全独立控制面 物理/VM 级别隔离 ✅ 隔离最强 ⚠️ 管理成本高 虚拟集群 租户 A → vCluster A 租户 B → vCluster B 共享底层节点 独立 API 模拟 ✅ 隔离与效率平衡 🔧 需额外工具 本课程聚焦“Namespace 即租户”模型，因为它最契合 CI/CD 流水线自动化场景

1.3 为什么需要自动化 RBAC

在多租户 K8s 环境中，手动管理 RBAC 配置会带来以下严重问题：

  • 配置爆炸：假设有 20 个租户、每个租户 3 个角色、每个角色绑定 5 个用户，手动创建 20×3×5 = 300 个 YAML 文件极易出错。
  • 权限漂移：团队人员变动（入职/离职/转岗）时，手动更新 RoleBinding 往往滞后数天，导致权限过大或权限缺失。
  • 审计困难：没有统一的 RBAC 变更记录，安全审计时无法回答“谁在何时获得了什么权限”。
  • 流水线阻塞：CI/CD 流水线在创建新 Namespace 后，需要等待运维手动配置 RBAC，导致发布延迟。
🔑 自动化 RBAC 的核心价值：将 RBAC 配置代码化（Policy as Code），通过 Git 仓库管理角色定义与绑定关系，由流水线自动执行 kubectl apply 或调用 K8s API，实现“创建租户即自动分配权限”。

1.4 自动化 RBAC 的典型工作流

下图展示了从“租户创建请求”到“RBAC 自动生效”的完整流程：

自动化 RBAC 工作流 自动化 RBAC 工作流 Git 提交 租户 RBAC YAML CI 流水线 校验 + 渲染 CD 部署 kubectl apply K8s 集群 RBAC 自动生效 审计日志回写 Git（可选） 自动化 RBAC 的关键收益 ✅ 租户创建 → 权限自动分配（< 1 分钟） ✅ 权限变更可追溯、可回滚 ✅ 消除人为配置错误，满足合规审计要求

1.5 自动化 RBAC 的典型场景

场景 手动操作痛点 自动化方案
新项目上线 运维手动创建 Namespace + RoleBinding，耗时 30 分钟 流水线根据 Git 仓库中的 tenant.yaml 自动执行
团队成员入职 管理员编辑多个 RoleBinding YAML，容易遗漏 在 Git 中新增 UserBinding 条目，流水线自动同步
权限回收 离职人员权限未及时清理，存在安全风险 删除 Git 中对应条目，流水线自动移除绑定
环境复制 从 Staging 复制 RBAC 到 Production，手动修改易出错 使用 Kustomize 或 Helm 模板化，参数化环境差异
⚠️ 常见误区：不要将自动化 RBAC 等同于“所有用户都使用 cluster-admin”。自动化 RBAC 的目标是最小权限原则（Least Privilege），即每个租户只获得完成工作所需的最小权限集合。

1.6 本课程将如何构建自动化 RBAC

在后续章节中，我们将逐步实现以下自动化 RBAC 体系：

  • 第 2-5 章：K8s RBAC 核心资源详解（Role、ClusterRole、RoleBinding、ClusterRoleBinding、ServiceAccount）。
  • 第 6-10 章：多租户 RBAC 模板化设计（Helm Chart + Kustomize）。
  • 第 11-15 章：CI/CD 流水线集成（GitOps 模式 + ArgoCD / Flux）。
  • 第 16-20 章：高级隔离策略（NetworkPolicy + OPA/Gatekeeper 策略引擎）。
  • 第 21-25 章：审计与合规（RBAC 变更审计、权限扫描工具）。
  • 第 26-30 章：生产级实战案例与故障排查。

通过本课程的学习，你将能够设计并落地一套可扩展、可审计、自动化的多租户 RBAC 体系，让 K8s 发布流水线真正实现“租户自服务、权限零等待”。

← 上一章 📖 返回目录 下一章 →