The road to data security: Databend user and role management application

[Live broadcast preview] Will large models replace programmers? "

Databend currently supports role-based access control (RBAC) and discretionary access control (DAC) models for access control functionality.

Through this guide, we will understand the basic concepts of permissions and roles in Databend, as well as how to manage roles, inherit roles and establish hierarchies, set default roles, and the importance of ownership. These functions enable users to flexibly configure and manage data access permissions according to actual needs, simplifying the complexity of permission management and improving the efficiency of data security control.

basic concept

When a user accesses a Data Object in Databend, the user must be granted the appropriate permissions or roles, or they need to have ownership of the data object. Data objects can refer to various elements such as databases, tables, views, stages, or UDFs.

Privilege plays a crucial role when interacting with data objects in Databend. These permissions, such as read, write, and execute, provide precise control over user behavior, ensuring consistency with user needs and maintaining data security.
Roles simplify access control. Roles are predefined sets of permissions assigned to users, simplifying permission management. Administrators can classify users according to their responsibilities and grant permissions efficiently without the need for separate configuration.
Ownership is an independent permission in Databend and is used to control data access. When a user takes ownership of a data object, the user has the highest level of control over the data object. This direct ownership model enables users to manage their own data more directly.

Permission type

Users need specific permissions to perform specific operations in Databend. For example, to query a table, the user needs at least SELECT permission on the table, and to read the data set in the Stage, the user needs at least READ permission on the stage.

The objects currently taken over by permission types include DB, Table, UDF, STAGE

Permissions	Object type	describe
ALL	global	Grants all permissions on the specified object type.
ALTER	global, database, table, view	Modify database, table, user or UDF.
CREATE	global, database, table	Create a database, table or UDF.
DELETE	surface	Delete or truncate rows in the table.
DROP	global, database, table, view	Drop a database, table, view, or UDF. Restore deleted tables.
INSERT	surface	Insert rows into the table.
SELECT	Database Table	Select rows from the table. Display or use the database.
UPDATE	surface	Update rows in the table.
GRANT	overall situation	Grant/revoke permissions from users or roles.
SUPER	global table	Terminate query. Set global configuration. Optimize tables. Analysis Table. Operate Stages (list Stages. Create, delete Stages), directories or shares.
USAGE	overall situation	Synonym for "no permissions".
CREATE ROLE	overall situation	Creating a Role.
DROP ROLE	overall situation	Delete the role.
CREATE USER	overall situation	Create SQL user.
DROP USER	overall situation	Delete SQL user.
WRITE	Stage	Write to Stage.
READ	Stage	Read Stage.
USAGE	UDF	Use UDF.

To grant ALL permissions to a table to a user/role is as follows:

grant all on db_name.table_name to role <role_name>;
grant all on db_name.table_name to <user_name>;

management role

Roles play a vital role in Databend and simplify permission management. When multiple users require the same set of permissions, granting permissions individually can be cumbersome. Roles provide a solution by allowing a set of permissions to be assigned to a role, which can then be easily assigned to multiple users.

For example, at the beginning, if the user wants user u1 to read the data of tables db.t and db.t2, he needs to execute the following SQL:

grant select on db.t to u1;
grant select on db.t2 to u1;

At this time, the new user u2 also needs to read the data of db.t and db.t2, and the administrator needs to continue executing the following SQL:

grant select on db.t to u2;
grant select on db.t2 to u2;

If there is a continuous stream of new users who need to read the same objects, the administrator will be immersed in these cumbersome user rights management, and it is very likely that misoperation will lead to access. These tedious operations can be optimized by roles:

-- 将 db.t 和 db.t2 的读取权限授权给角色 role1
grant select on db.t to role role1;
grant select on db.t2 to role role1;
-- 将 role1 的权限授予 u1
grant role role1 to u1;
-- 将 role1 的权限授予 u2
grant role role1 to u2;

If you want to query more tables such as t3, you only need to authorize role1 once, and all users who are granted role1 can read table t3.

-- 执行此 grant 后，u1 和 u2 可以读取 t3 的数据
grant select on db.t3 to role role1;

Databend supports querying user and role information, see Users and Roles .

Built-in roles

Databend introduces two built-in roles:

account-admin: Has all permissions, acts as a parent role to all other roles, and allows seamless switching to any role within the tenant.
public: Does not inherit any permissions, treats all roles as their parent roles, and allows any role to switch to the public role.

To assign a role to a user in Databend Cloud account-admin, select the role when inviting the user. You can also assign roles after users join. If you are using Databend Community or Enterprise Edition, first configure a account-adminuser during deployment and then assign roles to other users as needed. For more information about configuring administrator users, see Configuring Administrator Users .

Inherit roles & create hierarchies

Databend roles introduce a powerful mechanism through role delegation, enabling one role to inherit the permissions and responsibilities of another role. This helps create a flexible hierarchy, similar to an organizational structure, where there are two built-in roles : the highest-level role is account-adminand the lowest-level role is public.

Consider a scenario where three roles are created: manager , engineer and intern . In this example, the intern role is granted to the engineer role. Therefore, engineers not only have their own set of permissions, but also inherit the permissions associated with the intern role. Extending this hierarchy further, if the engineer role is granted to a manager , the manager now has the inherent permissions of the engineer and intern roles.

Set default role

When a user is granted multiple roles, you can use the CREATE USER or ALTER USER command to set a default role for the user. The default role determines the role a user is automatically assigned at the start of a session:

Users can switch to other roles within a session using the SET ROLE command.
Users can use the SHOW ROLES command to check their current roles and view all roles granted to them.
If you do not explicitly set a default role for a user, Databend will default to using the built-in role publicas the default role.

For example, grant the role dba to user xiaoming, and set the role dba as xiaoming's default role.

grant role dba to user xiaoming;
alter user xiaoming with DEFAULT_ROLE = dba;

ownership

Simply put, ownership means that a certain role completely owns a certain data object. Having ownership means that the role can perform any access operation on the data object (including deleting the data object).

Ownership will only act on role and is unique. Therefore, granting ownership or revoke ownership of a data object to a user are not supported operations.

-- 在 Databend 中为非法操作
grant ownership on db.t to user u1;
revoke ownership on db.t from user u1;

Ownership makes authorization easier. As long as it is a data object created by the current user, it can be accessed directly. There is no need to perform authorization operations on the same data object repeatedly:

-- 由管理员进行用户和角色的创建，并且将角色授予对应的用户
create role role1;
create user u1 identified by '123' with DEFAULT ROLE 'role1';
grant create on db.* to role role1;
grant role role1 to u1;

-- u1 登陆数据库后，此时 role1 已经被授予了 u1 ，所以u1 可以访问自己在 db 下创建的表：
u1> create table db.t(id int);
u1> insert into db.t values(1);
u1> select * from db.t;
u1> select * from db.t_old_exists -- 失败，因为该表的 owner 并不是角色 role1

At this time, if u2 also wants to access the resources created by u1, the administrator only needs to execute a SQL:

-- 管理员将角色 role1 授予用户 u2
grant role role1 to u2;

When we no longer want u1 to access these objects, the administrator only needs to execute one SQL:

-- 管理员撤销用户 u1 的角色 role1
revoke role role1 from u1;

You can use SHOW GRANTS to view detailed information about users and roles.

Note : Ownership is a specialized permission that indicates that a role fully owns a specific data object within Databend (currently including databases, tables, UDFs, and stages). Ownership of a data object is automatically granted to the current role of the user who created it. Users who share the same role also have ownership of the object, and can subsequently grant ownership of the data object to other roles through the administrator (refer to the GRANT command).

Ownership can only be granted to roles; ownership is not allowed to be granted to users. Once transferred from one role to another, ownership is transferred to the new role.

If the role that holds ownership of an object is removed, account_admin can grant ownership of the object to another role.

Ownership cannot be granted for defaulta table in the database because it account_adminis owned by a built-in role.

For security reasons, it is not recommended to grant ownership to built-in roles public. If a user is in the role when creating an object public, all users will have ownership of the object because every Databend user has publicthe role by default. Databend recommends creating and assigning custom roles to users rather than using publicroles to clearly manage ownership. The following example account-adminassigns roles to new and existing users:
-- 将默认角色 account_admin 授予现有用户作为 root
root ALTER USER u1 WITH DEFAULT_ROLE = 'account_admin';
root grant role u1 to writer;

-- 作为 root 创建一个默认角色为 account_admin 的新用户
root create user u2 identified by '123' with DEFAULT_ROLE='account_admin';
root grant role account_admin to u2;
Deleting a data object revokes ownership of the data object from the owner role. Restoring (UNDROP, if available) a deleted data object will not restore ownership. In this case, you will need to account_admingrant ownership to the role again.

Conclusion

Through permissions and role management, Databend provides a flexible data security management and control framework. Allows users to efficiently manage data access and operation permissions according to their own needs. Ensure data security and integrity.