StarRocks 权限系统详解：基于 RBAC 与 IBAC 的细粒度访问控制-港品优选

StarRocks 权限系统详解：基于 RBAC 与 IBAC 的细粒度访问控制

【免费下载链接】starrocksThe world's fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks

StarRocks 从 v3.0 开始构建了全新的权限体系，通过角色访问控制（RBAC）与身份访问控制（IBAC）双模型，支持对 Catalog、Database、Table、View、Materialized View 等对象进行细粒度的权限管控。本文以官方权限总览文档为核心，结合 FE 端源码与配套管理文档，系统讲解 StarRocks 权限系统的对象模型、用户身份、角色体系、权限继承与激活机制，帮助你设计出安全、可维护的多租户权限方案。

权限系统概览

权限决定了"哪些用户可以对哪些对象执行哪些操作"。StarRocks 的权限系统提供两层能力：一方面保障数据与资源的安全，另一方面允许管理员以细粒度方式管控整个集群。

版本说明：本文描述的特权体系仅自 v3.0 起可用。v3.0 的特权框架与语法与早期版本不向后兼容。从旧版本升级到 v3.0 后，除个别操作外，你原有的大部分权限会被保留。详细差异见权限支持清单末尾的 Upgrade notes 一节。

StarRocks 采用两种权限模型：

基于角色的访问控制（RBAC）：先把权限授予角色，再把角色授予用户，权限通过角色传递给用户；
基于身份的访问控制（IBAC）：权限直接授予用户身份。

因此，每个用户身份的最大权限范围 = 该身份自身的权限 ∪ 该身份被授予的所有角色的权限（即取并集）。

权限系统的基本概念

理解 StarRocks 权限系统，需要先掌握四个核心概念：

概念	含义	示例
对象（Object）	可以被授予访问权的实体；除非被授权，否则默认拒绝访问	CATALOG、DATABASE、TABLE、VIEW 等
权限（Privilege）	对对象已定义的访问级别，多个权限组合可以控制访问粒度；权限与对象强相关，不同对象可拥有不同权限	SELECT、ALTER、DROP
用户身份（User Identity）	用户的唯一标识，也是可以被授予权限的实体	`username@'userhost'`
角色（Role）	可被授予权限的实体，是权限的抽象集合；角色可授予用户，也可授予其他角色形成层级	`db_admin`、`cluster_admin`

在模型中，对象访问通过授予角色和用户的权限来放行；角色又可以被授予其他角色或用户，从而形成权限传递与继承。

对象与权限

StarRocks 中的对象存在逻辑层级关系：Database 包含在 Catalog 中，而 Table、View、Materialized View、Function 又包含在 Database 中。

每个对象都对应一组可被授予的权限项，这些权限定义了在该对象上可以执行的操作。你通过 GRANT 和 REVOKE 命令将权限授予或回收自角色与用户。

各对象支持的权限项

不同对象类型的权限项各不相同。以下是核心对象的权限清单（完整清单见 Privileges supported in StarRocks）：

TABLE：ALTER（修改表/刷新外表元数据）、DROP、SELECT、INSERT、UPDATE、EXPORT、DELETE、ALL。

DATABASE：ALTER（设置属性/改名/设置配额）、DROP、CREATE TABLE、CREATE VIEW、CREATE FUNCTION、CREATE MATERIALIZED VIEW、ALL。

VIEW：SELECT、ALTER（修改视图定义）、DROP、ALL。

MATERIALIZED VIEW：SELECT、ALTER、REFRESH（刷新物化视图）、DROP、ALL。

CATALOG：内部 Catalog（default_catalog）支持USAGE、CREATE DATABASE、ALL；外部 Catalog 支持USAGE、DROP、ALL。注意：StarRocks 内部 Catalog 不可被删除。

SYSTEM / RESOURCE GROUP / RESOURCE / USER / FUNCTION / STORAGE VOLUME / WAREHOUSE：分别定义了集群级、资源组、资源、用户（如IMPERSONATE允许用户 A 以用户 B 身份执行操作）、UDF（USAGE/DROP）、存储卷（ALTER/DROP/USAGE）等对象的专属权限。

用户与用户身份

StarRocks 中每个用户由唯一用户 ID 标识，它由 IP 地址（user host）和用户名构成，格式为username@'userhost'。相同用户名、不同来源 IP 被识别为不同的用户身份。例如user1@'172.65.xx.1'与user1@'172.65.xx.2'是两个不同的用户身份。

用户身份的另一种表示形式是username@['domain']，其中domain是一个可被 DNS 解析为一组 IP 的域名，最终会被展开为一组username@'userhost'。userhost部分支持用%做模糊匹配；如果不指定userhost，默认值为'%'，表示同名用户可从任意主机登录。

给用户授予权限

用户是权限的授予实体，权限与角色都可以授予用户。每个用户身份的最大权限范围是其自身权限与被授予角色权限的并集，StarRocks 保证每个用户只能执行被授权的操作。

官方推荐在多数场景下通过角色传递权限：先创建角色并为其授予权限，再把角色分配给用户；仅在需要临时或特殊权限时，才直接授予用户。这样既简化了权限管理，又保留了灵活性。

角色体系

角色是权限授予与回收的载体，可以视为可分配给用户的权限集合。一个用户可以被分配多个角色，从而用不同的权限集执行不同操作。为了简化管理，StarRocks 推荐通过角色管理权限，特殊与临时权限直接授予用户。

角色的一个关键特性是：激活后才生效。用户登录后，默认角色会自动激活；用户也可在会话内手动激活自己拥有的角色。

系统定义角色

StarRocks 提供多类系统定义角色（在仓库文档 Built-in Roles 中系统归纳为 5 个内置角色），其权限范围不可修改：

root：拥有全局权限。StarRocks 集群创建后自动生成拥有 root 权限的 root 用户。由于 root 用户与角色拥有系统全部权限，建议后续操作创建新用户与新角色，防止风险操作，并妥善保管 root 密码。
cluster_admin：拥有集群管理权限，可执行节点相关操作（添加、删除、下线节点）。不建议将cluster_admin或包含该角色的自定义角色设置为任何用户的默认角色，以防止意外节点变更。
db_admin：拥有数据库管理权限，可对 catalog、database、table、view、materialized view、function、global function、resource group、plug-in 执行全部操作。
user_admin：拥有用户与角色管理权限，可创建用户、角色和授予权限。其权限范围为SYSTEM级别的GRANT权限。
security_admin：内置安全管理员，负责管理 security integration 与 group provider，权限范围为SYSTEM级别的SECURITY与OPERATE。

此外，StarRocks 还提供系统定义角色public：任何用户都拥有该角色，并在任何会话中默认激活（包括新添加的用户）。public角色默认没有任何权限，但可以修改其权限范围——这是将特定权限授予集群内所有用户的推荐方式。

自定义角色

你可以按业务需求创建自定义角色并修改其权限范围。同时，为了方便管理，可以将角色授予其他角色，构建权限层级与继承：被关联角色的权限会被另一个角色继承。

如上图所示：

role_s被授予role_p，则role_p隐式继承role_s的priv_1；
role_p被授予role_g，则role_g隐式继承role_p的priv_2以及role_s的priv_1；
角色被授予用户后，用户同样获得该角色所继承的全部权限。

限制：角色的最大继承层级数默认为 16，且继承关系不能是双向的（环状继承会被拒绝）。

从源码看，这两个限制在 FE 中以动态参数形式存在（见 Config.java）：

privilege_max_total_roles_per_user（默认 64）：单个用户最多可拥有的角色数（含所有直接角色与全部祖先角色），可通过 FE 动态参数调整；
privilege_max_role_depth（默认 16）：允许的最大角色继承深度，用于避免合并权限时产生性能问题。

在 AuthorizationMgr.java 的grantRoleToRole实现中，FE 会先校验目标角色是否已是子角色的"祖先角色"（防止环），再校验继承深度是否超过privilege_max_role_depth；授予用户角色时（第 575-583 行）则会统计全部祖先角色数量并对照privilege_max_total_roles_per_user进行上限检查。此外，PUBLIC角色对所有用户和角色隐式生效，无法被显式授予或回收。

活动角色（Active roles）

活动角色允许用户在当前会话中应用角色的权限。使用SELECT CURRENT_ROLE();可以查看当前会话的活动角色，详见 current_role。

默认角色（Default roles）

默认角色在用户登录集群时自动激活，可以是用户拥有的一个或多个角色。管理员通过 CREATE USER 中的DEFAULT ROLE关键字设置默认角色，通过 ALTER USER 修改默认角色；用户也可以使用 SET DEFAULT ROLE 修改自己的默认角色。

默认角色为用户提供基础权限保护。例如，用户 A 拥有role_query（查询权限）和role_delete（删除权限），建议仅将role_query设为默认角色，防止DELETE、TRUNCATE等高危操作造成数据丢失；确需执行这些操作时，可手动设置活动角色后再执行。

没有默认角色的用户登录后仍然拥有public角色，该角色会在登录后自动激活。

手动激活角色

除默认角色外，用户可以在会话内手动激活一个或多个已拥有的角色。使用 SHOW GRANTS 查看可激活的权限与角色，使用 SET ROLE 配置当前会话生效的活动角色。

注意：SET ROLE命令会互相覆盖。例如用户登录后默认激活default_role，随后执行SET ROLE role_s，此时用户只拥有role_s的权限与自身权限，default_role被覆盖。若希望启用全部角色，可执行SET ROLE ALL。

权限与角色的管理实操

完整的用户、角色、权限管理操作（含全部 SQL 示例）见 Manage user privileges，以下为核心命令速览。

查看权限与角色

-- 查看当前用户的权限（任何用户无需权限即可查看自己的权限） SHOW GRANTS; -- 查看指定用户的权限 SHOW GRANTS FOR jack@'172.10.1.10'; -- 查看指定角色的权限 SHOW GRANTS FOR ROLE example_role; -- 查看集群内所有角色 SHOW ROLES;

拥有系统定义角色user_admin的用户可以查看集群内所有用户与角色信息。

角色管理

-- 创建角色（默认每个用户最多 64 个角色） CREATE ROLE example_role; -- 将角色授予用户 / 另一角色 / 外部认证系统的用户组 GRANT example_role TO USER jack@'172.10.1.10'; GRANT example_role TO ROLE test_role; GRANT example_role TO EXTERNAL GROUP analysts; -- 用户组来自外部认证系统 -- 设置用户的默认角色（两种等价写法；db1_admin 必须已授予 jack） SET DEFAULT ROLE 'db1_admin' TO jack@'172.10.1.10'; ALTER USER jack@'172.10.1.10' DEFAULT ROLE 'db1_admin'; -- 回收角色（注意：无法回收系统定义角色 PUBLIC） REVOKE example_role FROM USER jack@'172.10.1.10'; REVOKE example_role FROM ROLE test_role; -- 删除角色（系统定义角色不可删除） DROP ROLE example_role;

如果希望所有用户登录时自动启用全部角色（含默认角色与被授予角色），需要OPERATE系统权限，执行：

SET GLOBAL activate_all_roles_on_login = TRUE;

权限授予与回收

-- 授予用户 SELECT 权限，并通过 WITH GRANT OPTION 允许其再授予他人 GRANT SELECT ON TABLE sr_member TO USER jack@'172.10.1.10' WITH GRANT OPTION; -- 授予角色权限 GRANT SELECT ON TABLE sr_member TO ROLE example_role; -- 回收用户/角色的权限 REVOKE SELECT ON TABLE sr_member FROM USER jack@'172.10.1.10'; REVOKE SELECT ON TABLE sr_member FROM ROLE example_role;

拥有user_admin角色的用户才能执行权限与角色的授予、回收。若 GRANT 语句包含WITH GRANT OPTION，则被授权者可将该语句涉及的权限再授予其他用户或角色。

最佳实践：多业务线访问控制

以公司级集群为例：集群由服务提供商统一管理，承载多条业务线（LOB），每条业务线使用一个或多个数据库。不同成员在不同库表上执行不同操作，因此建议按服务与岗位创建角色，为每个角色只赋予必要权限，再将角色分配给对应成员。

推荐的落地步骤（完整示例见 Manage user privileges）：

集群维护者：授予系统定义角色db_admin、user_admin、cluster_admin，将db_admin与user_admin设为默认角色用于日常维护，仅在操作集群节点时手动激活cluster_admin：
```
GRANT db_admin, user_admin, cluster_admin TO USER user_platform; ALTER USER user_platform DEFAULT ROLE db_admin, user_admin;
```
各业务线成员：为每位成员创建用户并设置复杂密码。

按岗位建角色：为每条业务线的负责人授予其业务线所需的最大权限集并带WITH GRANT OPTION，使其能向下分发权限；为分析师与管理者分别创建查询类角色：

GRANT SELECT, ALTER, INSERT, UPDATE, DELETE ON ALL TABLES IN DATABASE DB_A TO ROLE linea_admin WITH GRANT OPTION; GRANT SELECT, ALTER, INSERT, UPDATE, DELETE ON TABLE TABLE_C1, TABLE_C2, TABLE_C3 TO ROLE linea_admin WITH GRANT OPTION; GRANT linea_admin TO USER user_linea_admin; ALTER USER user_linea_admin DEFAULT ROLE linea_admin; GRANT SELECT ON ALL TABLES IN DATABASE DB_A TO ROLE linea_query; GRANT linea_query TO USER user_linea_salesa; ALTER USER user_linea_salesa DEFAULT ROLE linea_query;

公共库访问：对需要全员访问的DB_PUBLIC，将 SELECT 权限授予系统定义角色public：
```
GRANT SELECT ON ALL TABLES IN DATABASE DB_PUBLIC TO ROLE public;
```

复杂场景使用角色继承：若分析师需要写入并查询DB_PUBLIC中的表，而管理者只能查询，可创建public_analysis与public_sales两个角色并分别授予写/读权限，再将这些角色授予原有分析师、管理者角色，实现权限的按需叠加：

CREATE ROLE public_analysis; CREATE ROLE public_sales; GRANT SELECT, ALTER, INSERT, UPDATE, DELETE ON ALL TABLES IN DATABASE DB_PUBLIC TO ROLE public_analysis; GRANT SELECT ON ALL TABLES IN DATABASE DB_PUBLIC TO ROLE public_sales; GRANT public_analysis TO ROLE linea_analysis; GRANT public_sales TO ROLE linea_query;

升级到 v3.0 的注意事项

从 v2.x 升级到 v3.0 时，新权限系统的引入可能导致部分操作无法执行，官方文档（Privileges supported in StarRocks）记录了以下关键差异：

操作	升级前	升级后
修改表（ALTER TABLE、CANCEL ALTER TABLE）	拥有表或库的`LOAD_PRIV`即可	必须拥有表的 ALTER 权限
刷新外表（REFRESH EXTERNAL TABLE）	拥有外表的`LOAD_PRIV`即可	必须拥有外表的 ALTER 权限
备份恢复（BACKUP、RESTORE）	拥有库的`LOAD_PRIV`即可	管理员需在升级后重新授予备份恢复权限
删除后恢复（RECOVER）	拥有库表的`ALTER_PRIV`/`CREATE_PRIV`/`DROP_PRIV`	需在 default_catalog 上有 CREATE DATABASE 权限，在库上有 CREATE TABLE 权限、表上有 DROP 权限
创建与修改用户（CREATE USER、ALTER USER）	拥有库的`GRANT_PRIV`即可	必须拥有`user_admin`角色
授予/回收权限（GRANT、REVOKE）	拥有对象的`GRANT_PRIV`即可	需拥有`user_admin`角色；若 GRANT 语句含`WITH GRANT OPTION`，可将语句涉及的权限授予他人

另外需要特别说明：v2.x 并未完整实现 RBAC。在 v2.x 中，将角色授予用户时，StarRocks 直接授予该角色的全部权限而非角色本身，因此用户实际上并不拥有该角色。升级到 v3.0 后，原有角色会被保留，但用户与角色之间仍不存在从属关系；如需使用新的 RBAC 体系，请通过 GRANT 操作重新建立角色与权限的关联。

企业官网建设流程全解析