Status

Current state: [One of "Under Discussion", "Accepted", "Rejected"]

Discussion thread: 

JIRA or Github Issue: 

Released: <Doris Version>

Google Doc: <If the design in question is unclear or needs to be discussed and reviewed, a Google Doc can be used first to facilitate comments from others.>

Motivation

RBAC (Role-Based Access Control) controls the permissions of users by defining the permissions of roles and granting users a certain role, which realizes the logical separation of users and permissions, and greatly facilitates the management of permissions.

Related Research

clickhouse: https://clickhouse.com/docs/zh/sql-reference/statements/create/roleredshift: https://www.youtube.com/watch?v=IhHQ7mZ-tp4
Snowflake: https://www.youtube.com/watch?v=pZQXK7qO0iY

Detailed Design

Users can have multiple roles, roles can have multiple permissions, and users cannot be authorized directly (the underlying implementation).

When performing grant or revoke operations on a user, the bottom layer is actually to find the user's default role (starting with default_role_rbac_, spliced with username and host or domain), and then operate permissions on the default role.

When a user's permission is queried, it is actually the union of the permissions of all roles of the user. Therefore:

1. When using drop role to delete a role, all users who have the role will lose the permissions that the role has.

2. When grant or revoke is used to operate permissions on a role, the permissions of all users who have the role will also be indirectly operated.

Main data structure:

1. UserManager stores all users

2. RoleManager stores all roles and their permissions

3. UserRoleManager stores the relationship between users and roles

Scheduling

1.Transformation of underlying data structure（https://github.com/apache/doris/pull/16091）

2.Expand more commands, such as setting user roles