Перейти к основному содержимому
Перейти к основному содержимому

Запросы управления доступом

Самоуправляемый

Если вы работаете с самоуправляемым ClickHouse, пожалуйста, посмотрите SQL пользователи и роли.

В этой статье рассмотрены основы определения SQL пользователей и ролей, а также применения этих привилегий и разрешений к базам данных, таблицам, строкам и колонкам.

Администраторский пользователь​

Службы ClickHouse Cloud имеют администратора, default, который создается при создании службы. Пароль предоставляется при создании службы и может быть сброшен пользователями ClickHouse Cloud, имеющими роль Admin.

Когда вы добавляете дополнительных SQL пользователей для вашей службы ClickHouse Cloud, им потребуется SQL имя пользователя и пароль. Если вы хотите, чтобы у них были привилегии уровня администратора, назначьте новым пользователям роль default_role. Например, добавление пользователя clickhouse_admin:

примечание

При использовании SQL Консолей ваши SQL инструкции не будут выполняться от имени пользователя default. Вместо этого инструкции будут выполняться от имени пользователя sql-console:${cloud_login_email}, где cloud_login_email — это электронная почта пользователя, который в данный момент выполняет запрос.

Эти автоматически сгенерированные пользователи SQL Консолей имеют роль default.

Аутентификация без пароля​

Для SQL консоли доступны две роли: sql_console_admin с идентичными правами к default_role и sql_console_read_only с правами только для чтения.

Администраторским пользователям по умолчанию назначается роль sql_console_admin, поэтому для них ничего не меняется. Однако роль sql_console_read_only позволяет неадминистраторским пользователям получать доступ только для чтения или полный доступ к любому экземпляру. Администратор должен настроить этот доступ. Роли можно корректировать с помощью команд GRANT или REVOKE для более точного соответствия требованиям конкретного экземпляра, и любые изменения, внесенные в эти роли, будут сохранены.

Гранулярный контроль доступа​

Эта функциональность контроля доступа также может быть настроена вручную для гранулярности на уровне пользователя. Прежде чем назначить новые роли sql_console_* пользователям, должны быть созданы специфические для базы данных роли пользователей SQL консоли, соответствующие пространству имен sql-console-role:<email>. Например:

Когда будет обнаружена соответствующая роль, она будет назначена пользователю вместо стандартных ролей. Это вводит более сложные конфигурации контроля доступа, такие как создание ролей, таких как sql_console_sa_role и sql_console_pm_role, и назначение их конкретным пользователям. Например:

Test admin privileges​

Log out as the user default and log back in as user clickhouse_admin.

All of these should succeed:

Non-admin users​

Users should have the privileges necessary, and not all be admin users. The rest of this document provides example scenarios and the roles required.

Preparation​

Create these tables and users to be used in the examples.

Creating a sample database, table, and rows​

  1. Create a test database

  2. Create a table

  3. Populate the table with sample rows

  4. Verify the table:

  5. Create a regular user that will be used to demonstrate restrict access to certain columns:

  6. Create a regular user that will be used to demonstrate restricting access to rows with certain values:

Creating roles​

With this set of examples:

  • roles for different privileges, such as columns and rows will be created
  • privileges will be granted to the roles
  • users will be assigned to each role

Roles are used to define groups of users for certain privileges instead of managing each user separately.

  1. Create a role to restrict users of this role to only see column1 in database db1 and table1:

  2. Set privileges to allow view on column1

  3. Add the column_user user to the column1_users role

  4. Create a role to restrict users of this role to only see selected rows, in this case, only rows containing A in column1

  5. Add the row_user to the A_rows_users role

  6. Create a policy to allow view on only where column1 has the values of A

  7. Set privileges to the database and table

  8. grant explicit permissions for other roles to still have access to all rows

    примечание

    When attaching a policy to a table, the system will apply that policy, and only those users and roles defined will be able to do operations on the table, all others will be denied any operations. In order to not have the restrictive row policy applied to other users, another policy must be defined to allow other users and roles to have regular or other types of access.

Verification​

Testing role privileges with column restricted user​

  1. Log into the clickhouse client using the clickhouse_admin user

  2. Verify access to database, table and all rows with the admin user.

  3. Log into the ClickHouse client using the column_user user

  4. Test SELECT using all columns

    примечание

    Access is denied since all columns were specified and the user only has access to id and column1

  5. Verify SELECT query with only columns specified and allowed:

Testing role privileges with row restricted user​

  1. Log into the ClickHouse client using row_user

  2. View rows available

    примечание

    Verify that only the above two rows are returned, rows with the value B in column1 should be excluded.

Modifying Users and Roles​

Users can be assigned multiple roles for a combination of privileges needed. When using multiple roles, the system will combine the roles to determine privileges, the net effect will be that the role permissions will be cumulative.

For example, if one role1 allows for only select on column1 and role2 allows for select on column1 and column2 then the user will have access to both columns.

  1. Using the admin account, create new user to restrict by both row and column with default roles

  2. Remove prior privileges for A_rows_users role

  3. Allow A_row_users role to only select from column1

  4. Log into the ClickHouse client using row_and_column_user

  5. Test with all columns:

  6. Test with limited allowed columns:

Troubleshooting​

There are occasions when privileges intersect or combine to produce unexpected results, the following commands can be used to narrow the issue using an admin account

Listing the grants and roles for a user​

List roles in ClickHouse​

Display the policies​

View how a policy was defined and current privileges​

Example commands to manage roles, policies, and users​

The following commands can be used to:

  • delete privileges
  • delete policies
  • unassign users from roles
  • delete users and roles
подсказка

Run these commands as an admin user or the default user

Remove privilege from a role​

Delete a policy​

Unassign a user from a role​

Delete a role​

Delete a user​

Summary​

This article demonstrated the basics of creating SQL users and roles and provided steps to set and modify privileges for users and roles. For more detailed information on each please refer to our user guides and reference documentation.