• 租户（Tenant）：租户是用户在 ByteHouse 企业版计费主体，租户下所有用户产生的费用均归属于租户。租户下有一个主用户与多个子用户。所有集群均属于不同的租户，租户之间的集群和数据完全隔离。
• 用户（User）：主用户与子用户统称用户。一个用户对应一个用户名与密码。
• 主用户（Main User）：一个火山引擎租户下必定有一个主用户。该用户拥有 ByteHouse 所有服务的访问权限并能在所属租户下创建子用户并分配特定的权限。
• 子用户（Sub-user）：由主用户在 ByteHouse 企业版系统中创建的用户，该用户创建时默认不具备任何 ByteHouse 的访问权限，需要主用户分配特定的权限策略之后，普通用户通过的主用户分配的子用户密码登录并使用 ByteHouse 的服务。
• 权限（Previlege）：表达是否允许用户对于数据对象的增、删、改、查等操作的抽象对象。
• 角色（Role）：角色即权限的集合。角色管理能够实现对项目中某个角色的用户批量授权，减少重复、繁杂的授权操作。 一个角色可以包含多个用户。角色是集群维度下的对象，一个用户可以在不同集群下被授予不同的角色。
• 数据对象（Data Object）：数据库内的实体。对于 ByteHouse 而言，数据对象包括以下实体： 数据库（Datebase），数据表（Table），列（Column），索引（Index），视图（View），投影（Projection），计算组（Virtual WareHouse）等。数据对象存在于一个集群内。

ByteHouse 的权限模型基于 ClickHouse 社区。ClickHouse 社区的默认权限体系为 RBAC 模型，支持用户（User）、角色（Role）、权限（Prevililege）、实体（Data Object）四元组的相互关联，通过 Revoke 和 Grant 语法进行互联操作。

单集群

在单个集群下，ByteHouse 企业版的权限模型如下：

• 可以将权限赋予角色，角色赋予用户。
• 也可以将权限直接赋予用户。

多集群

由于一套 ByteHouse 支持管理多个集群，我们将 ClickHouse 的权限模型进行了扩展。具体改动如下。

• 用户为跨集群的实体，可同时存在于不同的集群。

  • 用户名在租户内不允许重名。一个 ByteHouse 租户仅允许同名的一个用户。

  • 通过控制面，对用户进行修改密码操作时，同时影响用户所在的每一个集群。

  • 在创建用户时，可以将用户加入至少一个集群；

  • 在修改用户时，可以让用户加入或离开某集群。

  • 请勿直接连接集群，对集群的用户进行密码修改，会导致通过控制面无法对该集群下的表进行增、删、改、查的操作。

• 一般情况下，角色为集群维度下的实体。

  • 系统拥有四个默认角色：System Admin，Cluster Admin，Data Engineer，Query User。自定义角色不允许与四个角色重名。

  • 仅有一个默认角色是跨集群的角色：System Admin 。可认为 System Admin 是超级管理员：拥有全集群的全权限。

  • 在给用户授予角色时，必须先选择集群，再选择角色，此时用户会被加入该角色所在的集群；或直接授予 System Admin 角色，此时用户会被加入每一个集群。

  • 角色允许在不同集群中重名。在控制面展示角色时，同时显示该角色所在的集群。

• 权限由于和 DataObject（DB/Table/Column）关联，为集群下的实体。

  • 权限仅能被赋予本集群下的角色。

  • 当权限被赋予用户时，用户会自动被加入当前集群。

• 因此，ByteHouse 的 RBAC 模型示意图如下：