多租户管理
什么是 RTBAC
矩尺平台采用自研的 RTBAC（Role Tenant Based Access Control，基于角色与租户的访问控制）权限管理体系。它由三层概念构成：
用户（User） → 租户（Tenant） → 角色（Role）
你是谁 你在哪个组织里 你在该组织里能做什么与传统的 RBAC（只区分角色）不同，RTBAC 多了一层"租户"来做资源隔离。简单理解：
- 角色决定你能操作哪些功能（能不能创建虚拟服务、能不能管理转发引擎）
- 租户决定你能看到哪些资源（只能看到自己租户内的转发引擎、虚拟服务、服务器池等）
两者叠加，实现了"同一平台、多部门使用、互相不可见"的效果。
三层模型
角色（Role）—— 决定了"能做什么"
矩尺平台内置 5 种默认角色，每种角色的职责边界清晰：
| 角色 | 核心职责 | 典型使用者 |
|---|---|---|
| 系统管理员 | 全局管理：创建租户、用户、角色；管理许可证、升级、配置备份；创建全局共享的 SSL 证书 | 平台管理员（admin） |
| 租户管理员 | 基础设施管理：添加/管理转发引擎和第三方负载、配置用户凭证、管理网络资源；可创建子租户和管理本租户内用户与角色 | 网络/基础设施运维 |
| 应用管理员 | 业务配置：创建服务器池、虚拟服务、分发规则、策略、健康检查；查看监控排查问题 | 业务开发/运维工程师 |
| 安全管理员 | 证书与安全：管理 SSL 证书和 SSL 策略、访问控制 | 安全工程师 |
| 应用运维 | 只读运维：查看监控图表、分析页面、告警记录 | 初级运维、实习助理 |
各角色的菜单权限详见 角色管理。
系统管理员可使用全部功能。admin 为内置系统管理员账号，不可删除。
v4.1.0 起：租户管理员角色的默认权限已开放 用户管理 和 角色管理，允许租户管理员在本租户内创建用户、分配角色，无需系统管理员介入。
租户（Tenant）—— 决定了"能看到什么"
租户是资源隔离的基本单位，对应一个具体的组织，例如：
- 某个业务部门（交易组、用户组）
- 某个分公司（华东区、华南区）
- 某个项目团队（电商平台组、数据平台组）
租户的核心作用有两个：
管理上下文隔离：不同租户的用户登录后，只能看到自己租户内的资源（虚拟服务、服务器池、策略、告警配置等）。通过右上角切换租户可以看到不同租户下的资源：
数据面资源隔离：每个租户可以独占或共享转发引擎集群。这是 RTBAC 与纯 RBAC 的关键区别——不仅控制面隔离了"看什么"，数据面也隔离了"流量跑在哪些引擎上"。
用户（User）—— 连接人与租户+角色
用户是具体的登录账号。关键规则：
- 一个用户可以属于多个租户。例如工程师小 A 同时属于"总公司"租户和"分公司"租户。
- 同一用户在不同租户中可以有不同的角色。小 A 在"总公司"租户中是应用管理员，在"分公司"租户中可能是应用运维。
- 同一时刻只能在一个租户的上下文中操作，通过右上角切换。
这种设计允许一个工程师同时参与多个业务团队，在每个团队中有对应的权限，无需创建多个账号。
多级租户管理（v4.1.0 新增）
v4.1.0 起，矩尺支持多级授权管理：租户管理员可以在本租户下创建子租户，并委派子租户管理员，实现组织架构的逐级下放。
层级结构
系统管理员（admin）
└── 创建总公司租户，指定小 D 为租户管理员
└── 小 D 创建分公司 A 租户，指定 user1 为租户管理员
└── user1 创建部门 B 租户，指定 user2 为租户管理员
└── user2 创建部门内的普通用户（应用管理员、应用运维等）各级职责
| 层级 | 角色 | 可执行操作 |
|---|---|---|
| 系统管理员 | 系统管理员 | 创建顶层租户、管理全局配置、管理许可证 |
| 顶层租户管理员 | 租户管理员 | 创建子租户、为本租户和子租户创建用户和角色、管理基础设施、将转发引擎集群共享给子租户 |
| 子租户管理员 | 租户管理员 | 在本租户内创建用户和角色、使用获得的共享转发引擎集群创建业务资源 |
| 普通用户 | 应用管理员/应用运维等 | 使用本租户资源进行业务配置和运维 |
关键能力：顶层租户管理员无需关心子租户内部的用户管理。子租户的管理员可以自行创建本部门的用户和角色，实现了真正的分级自治。
资源隔离机制
控制面隔离
租户之间在控制面（Web 管理界面）上完全隔离：
- 租户 A 的用户登录后，菜单中看到的虚拟服务、服务器池、策略、分发规则、告警配置等，全部是租户 A 自己的资源
- 租户 B 的用户看不到租户 A 的任何配置
- 即使是同一个转发引擎上的不同虚拟服务，只要分属不同租户，互相也不可见对方配置
数据面隔离（转发引擎集群）
数据面的隔离通过转发引擎集群实现。支持独占和共享两种模式。
模式一：独占转发引擎集群
租户 A（交易组）→ 转发引擎集群 A（engine-01, engine-02）
租户 B（用户组）→ 转发引擎集群 B（engine-03, engine-04）每个租户独享自己的转发引擎，流量在物理层面隔离。适用于：
- 业务对安全隔离要求高（如金融交易系统）
- 业务流量大，需要独占硬件资源
- 合规要求（如等保）需要物理隔离
模式二：共享转发引擎集群
租户 A（总公司、集群创建者）↘
[转发引擎集群]（engine-01 ~ engine-04）
租户 B（分公司、集群使用者）↗多个租户共享同一套转发引擎，由集群创建者主动将集群共享给指定租户。
转发引擎集群共享机制（v4.1.0 变更）
v4.1.0 对转发引擎集群的共享方式做了重大改进：不再是在租户页面上配置共享开关，而是直接在转发引擎集群列表中进行共享设置。
共享设置
入口：【平台系统 → 基础设施 → 转发引擎集群】。
在转发引擎集群列表中，集群的创建者（Owner）可以点击"共享"按钮，将本集群共享给指定的一个或多个租户。
当前登录用户拥有多个租户身份时，可选择将集群共享给这些租户中的任意租户。
创建者与使用者
转发引擎集群引入创建者（Creator） 和 使用者（User） 角色：
| 角色 | 说明 | 权限 |
|---|---|---|
| 创建者 | 创建该集群的租户 | 对集群有完全的读写权限（增删转发引擎、修改集群网络策略、重命名等） |
| 使用者 | 被共享到的租户 | 仅有使用权限和网络配置权限，无权修改集群本身 |
被共享的转发引擎集群和转发引擎上会出现共享标志，方便识别。
使用者可执行的操作
被共享到的租户（使用者）对集群中的转发引擎：
- 可以在虚拟服务 / 流量组 / 浮动 IP / 服务器池中引用
- 可以在转发引擎管理中操作以下功能：
- 路由管理
- 本地 IP 管理
- 网络接口管理
- 网口聚合
- VLAN 管理
- 日志管理
使用者不能修改转发引擎的基本属性（如名称、通讯地址、SSH 凭证等），也不能对集群进行增删引擎或修改集群网络策略等操作。
资源共享机制
并非所有资源都严格隔离。矩尺的 RTBAC 允许部分资源在租户间共享：
| 资源类型 | 隔离/共享规则 |
|---|---|
| 虚拟服务 | 单租户独占，不可共享 |
| 服务器池 | 单租户独占，不可共享 |
| 策略（七层/四层/SSL/会话保持等） | 单租户独占，不可共享 |
| 分发规则、静态资源、告警配置 | 单租户独占，不可共享 |
| 转发引擎集群 | 默认独占，创建者可主动共享给指定租户 |
| SSL 证书 | 系统管理员创建的证书可多租户只读共享，租户内创建的证书仅本租户可用 |
| 健康检查（内置策略） | 全局只读，所有租户可用，不可删除 |
| 用户凭证 | 租户管理员创建的凭证仅本租户可用 |
配置示例
场景描述
某集团公司使用矩尺平台，组织结构如下：
集团平台管理员（小 E / 系统管理员）
└── 总公司租户（网络部门 / 小 D / 租户管理员）
├── 分公司 M 租户（交易业务 / 小 A / 租户管理员）
│ ├── 用户 小 A（应用管理员）
│ └── 用户 小 B（应用运维）
└── 分公司 N 租户（用户业务 / 小 C / 租户管理员）
└── 用户 小 C（应用管理员）- 小 E（系统管理员）：负责平台的顶层管理，创建总公司租户
- 小 D（总公司租户管理员）：负责基础设施，管理转发引擎集群，并共享给各分公司
- 小 A（分公司 M 租户管理员）：自行管理分公司 M 内的用户和业务
- 小 C（分公司 N 租户管理员）：自行管理分公司 N 内的用户和业务
配置步骤
1. 系统管理员小 E 创建顶层租户（使用 admin 账号）：
- 创建租户
总公司，指定小 D 为该租户下的用户，角色为"租户管理员"
2. 租户管理员小 D 添加基础设施：
- 以
总公司租户身份登录，创建 3 台转发引擎（engine-01、engine-02、engine-03） - 将它们组成一个转发引擎集群
cluster-main
注意：v4.1.0 起，创建转发引擎集群时需选择产品类型，集群 vCPU 总数不得超过该产品类型的 vCPU 上限。
3. 租户管理员小 D 创建子租户并委派：
- 创建子租户
分公司-M，并创建用户小A，角色为"租户管理员" - 创建子租户
分公司-N，并创建用户小C，角色为"租户管理员"
小 D 只需要创建到子租户管理员这一层，各分公司内部的人员管理由子租户管理员自行负责。
4. 租户管理员小 D 共享转发引擎集群：
- 进入【平台系统 → 基础设施 → 转发引擎集群】，找到
cluster-main - 点击"共享"，将集群共享给
分公司-M和分公司-N
这样两个分公司就有了转发引擎资源，但无法修改集群本身。
5. 分公司租户管理员自行管理内部用户：
小 A 切换到 分公司-M 租户上下文：
- 创建普通用户
小B，角色为"应用运维" - 小 B 即获得
分公司-M租户下资源的只读权限，可使用共享的转发引擎集群查看虚拟服务等资源
小 C 切换到 分公司-N 租户上下文：
- 该租户暂时只有小 C 一人，可以直接进行业务配置
6. 应用管理员配置业务：
小 A（应用管理员身份登录 分公司-M）：
- 创建服务器池、健康检查、虚拟服务等，转发引擎引用共享的
cluster-main - 小 B（应用运维）可以查看小 A 创建的配置和监控，但无法修改
- 小 C（不同租户的应用管理员）完全看不到
分公司-M的任何配置
7. 验证隔离效果：
- 分公司 M 和分公司 N 之间互不可见对方资源
- 总公司租户小 D 可以看到所有集群资源，但看不到各分公司内部的虚拟服务配置
- 各分公司可独立管理自己的用户和业务，无需总公司介入
传统平级租户模式（无多级授权）
如果您不需要多级租户管理，仍然可以采用传统的平级租户方式：
- 系统管理员直接创建所有租户（如
交易组-M、用户组-N） - 为每个租户创建用户并分配角色
- 各租户管理员自行管理转发引擎和业务配置