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