跳到主要内容
版本:Latest-3.3

权限系统总览

本文介绍 StarRocks 中权限系统的基本概念。权限决定了哪些用户可以对哪些特定对象执行哪些特定的操作,从而方便您更加安全地管控数据和资源。

版本提示:本文介绍的权限管理系统从 3.0 版本开始提供。升级后的权限框架、语法与旧的系统无法兼容,请以 3.0 版本的操作说明为准。升级后,除个别操作外,您在原有系统上的大部分操作权限仍然保留。具体差异请见权限项文档的升级注意事项

StarRocks 采用了两种权限模型:

  • 基于角色的访问控制 (RBAC: role-based access control):权限通过角色来进行管理,即可以将权限赋予给角色,从而通过角色传递给用户。
  • 基于用户标识的访问控制 (IBAC: identity-based access control):权限可以直接赋予给用户标识。

因此,每个用户标识拥有的最大权限范围为:它所拥有的角色权限及自身权限的并集。

基础概念:

  • 对象 (Object) 是一个可以被授权访问的实体。除非进行授权,否则拒绝访问。例如 CATALOG、DATABASE、TABLE、VIEW 等。
  • 权限项 (Privilege) 是一个对象的访问级别。不同的权限项代表着对目标对象的不同操作。例如 SELECT、ALTER、DROP 等。有关 StarRocks 支持的对象和权限项,参见 权限项
  • 用户标识 (User Identity):用户的唯一标识,同时也是可以被授权的实体。用户标识以 username@'userhost' 的方式呈现,由指定的用户名和用户登录的 IP 组成。用户标识简化了属性配置,相同用户名的用户标识共享一个属性。只需将属性配置给用户名,该属性会对所有包含该用户名的用户标识生效。
  • 角色 (Role):权限的抽象合集,同时也是可以被授权的实体。可以将角色授予给用户,也可以将角色授予给其他角色产生嵌套,从而将其权限向下传递。StarRocks 提供系统预置角色,您也可以根据业务需求创建自定义角色。

下图展示了在 RBAC 和 IBAC 两种权限模型下的权限管理示例。

privilege management

对象与权限

对象在逻辑上存在层级,这与他们所代表的概念有关。例如 Database 包含在 Catalog 中,而 Table、View、Materialized View、Function 又包含在 Database 中。下图展示了 StarRocks 系统中的对象层级关系。

privilege objects

对于每个对象,都有一组可以被授权的权限项,更多细节请查阅权限项文档。您可以通过 GRANTREVOKE 命令来对角色或用户进行权限的发放和收回。

用户

用户标识

在 StarRocks 中,每个用户都拥有唯一的用户标识。由用户登录的 IP(userhost) 和用户名(username)组成,写做:username@'userhost'。StarRocks 会将拥有相同用户名,但来自不同 IP 的用户识别为不同的用户标识,即 user1@'starrocks.com'user1@'mirrorship.com' 是两个用户标识。

用户标识的另一种表现方式为 username@['domain'],其中 domain 为域名,可以通过 DNS 解析为一组 IP。最终表现为一组 username@'userhost'。其中,userhost 的部分可以使用 % 来进行模糊匹配。如果不指定 userhost,默认为 '%',即表示从任意 host 连接到 StarRocks 的同名用户。

为用户授权

用户是可以被授权的实体,权限和角色均可以被赋予给用户。用户拥有的最大权限合集为自身权限与所拥有角色权限的并集。StarRocks 保证每个用户只能执行被授权的操作。

StarRocks 建议您在大部分情况下使用角色来分发权限。即,根据业务场景创建角色,将权限赋予给角色后,再将角色赋予给用户。对于特定用户拥有的临时、或特殊权限,通过将权限直接赋予给用户的方式进行管理。这样可以最大程度简化权限管理流程,并提供一定的灵活性。

角色

角色可以看做是一组权限的集合。为达到管理的简洁性,StarRocks 建议您将绝大部分日常权限尽量通过角色来进行管理,以避免重复性操作,保证一致性。对于特殊、临时的权限,可以直接赋予给用户。

为了方便管理,StarRocks 预置了几类具有特定权限的角色,你可以使用此类角色来满足日常管理需求。您也可以根据实际需求,灵活配置自定义角色。

角色激活后,用户可以执行对应角色拥有权限的操作。您可以为每个用户设置登录时自动激活的默认角色 (default role),用户也可以在当前会话中手动激活拥有的角色 (active role)。

系统预置角色

StarRocks 提供了几类预置角色(system-defined roles):

roles

  • root:拥有全局权限。root 用户默认拥有 root 角色。 StarRocks 集群最初创建时,系统会自动生成 root 用户,该用户拥有 root 权限。由于 root 用户、角色的权限范围过大,建议您在后续使用和维护集群时创建新的用户和角色,避免直接使用此用户和角色。root 用户的密码请您妥善保管。

  • cluster_admin:拥有集群的管理权限。包含对节点的操作权限,如增加、减少节点。 cluster_admin 角色拥有对集群节点的上、下线权限,请妥善赋权。建议您不要将 cluster_admin 或任何包含此角色的自定义角色设置为用户的默认角色,防止因误操作而导致的节点变更。

  • db_admin:拥有数据库的管理权限。包含所有 CATALOG、数据库、表、视图、物化视图、函数及全局函数、资源组、插件等对象的所有操作权限。

  • user_admin:拥有用户和角色的管理权限。包含创建用户、角色、赋权等权限。

    上述系统预置角色旨在将复杂的数据库权限进行高度集合,以方便您的日常管理,上述角色的权限范围不可以修改。

    除此之外,如果您需要将某些权限赋予给所有用户,StarRocks 还提供一个预置角色 public

  • public:任何用户都拥有、并在任何会话下都默认激活此角色,包含新增用户。public 角色默认不拥有任何权限,您可以对此角色的权限范围进行修改。

用户自定义角色

您可以根据业务场景创建自定义角色,并修改其权限范围。同时,为了方便管理,您可以通过将角色赋予给角色来产生权限的继承。

角色的继承关系

下图展示了权限继承的例子。

注意:一个角色的最多继承层数为 16。角色的继承关系不能是双向的,比如将角色 A 赋予给 B,不能同时又把 B 赋予给 A,可能会造成继承关系不清楚。

role inheritance

如图所示,将角色赋予给用户,用户也对应拥有了角色的权限。

  • role_s 被赋予给了 role_p,因此 role_p 隐含继承了 role_spriv_1
  • role_p 被赋予给了 role_g,因此 role_g 隐含继承了 role_ppriv_2role_spriv_1

激活角色

通过激活角色 (Active Role),用户可以将该角色的权限应用在当前会话下。您可以通过 SELECT CURRENT_ROLE() 来查看当前会话内激活的角色。

默认激活角色

默认角色(Default Role)即为用户登录集群时自动激活的角色,可以是 1 个或多个用户拥有的角色。管理员可以在创建用户时通过 CREATE USER 的 DEFAULT ROLE 关键字进行设置,也可以在后续通过 ALTER USER 进行更改。

同时用户也可以通过 SET DEFAULT ROLE 更改自己的默认角色。

默认角色为用户提供了一道基础的权限屏障。例如,用户 A 拥有 role_query 和 role_delete 两个角色,分别包含了查询和删除的权限。StarRocks 建议您仅将 role_query 作为默认角色,以防止误执行 DELETE 或 TRUNCATE 等高危操作而导致数据丢失。当您确认需要执行上述操作时,可以在手动设置激活角色后执行。

当用户没有默认角色时,在登录集群后自动激活系统预置的 public 角色。

手动激活角色

除了默认角色,用户也可以在会话内手动选择激活一个或多个已拥有的角色。您可以通过 SHOW GRANTS 命令查看当前用户拥有的权限和可以激活的角色,并通过 SET ROLE 命令来设置当前的激活角色,生效范围为当前会话。

SET ROLE 命令是覆盖的。例如,用户登录时是默认激活了 default_role,执行 SET ROLE role_s之后,用户此时拥有的是 role_s 的权限和自身权限。

相关文档

管理用户权限