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

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

Самостоятельное управление

Если вы работаете с самоуправляемым 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, и их назначение конкретным пользователям. Например:

Проверка привилегий администратора​

Выйдите из учетной записи default и войдите снова как пользователь clickhouse_admin.

Все из этих запросов должны успешно выполниться:

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

Пользователи должны иметь необходимые привилегии, а не все должны быть администраторами. Остальная часть этого документа предоставляет примеры сценариев и необходимые роли.

Подготовка​

Создайте эти таблицы и пользователей для примеров.

Создание тестовой базы данных, таблицы и строк​

  1. Создайте тестовую базу данных

  2. Создайте таблицу

  3. Заполните таблицу тестовыми строками

  4. Проверьте таблицу:

  5. Создайте обычного пользователя, который будет использован для демонстрации ограниченного доступа к определенным колонкам:

  6. Создайте обычного пользователя, который будет использован для демонстрации ограничения доступа к строкам с определенными значениями:

Создание ролей​

С этим набором примеров:

  • будут созданы роли для различных привилегий, таких как колонки и строки
  • привилегии будут предоставлены ролям
  • пользователи будут назначены каждой роли

Роли используются для определения групп пользователей для определенных привилегий, вместо управления каждой учетной записью отдельно.

  1. Создайте роль, чтобы ограничить пользователей этой роли видеть только column1 в базе данных db1 и table1:

  2. Установите привилегии для разрешения просмотра column1

  3. Добавьте пользователя column_user к роли column1_users

  4. Создайте роль, чтобы ограничить пользователей этой роли видеть только выбранные строки, в данном случае, только строки, содержащие A в column1

  5. Добавьте пользователя row_user к роли A_rows_users

  6. Создайте политику, чтобы разрешить просмотр только там, где column1 имеет значение A

  7. Установите привилегии для базы данных и таблицы

  8. предоставьте явные разрешения для других ролей, чтобы они все еще имели доступ ко всем строкам

    примечание

    При прикреплении политики к таблице, система применит эту политику, и только те пользователи и роли, которые определены, смогут выполнять операции с таблицей, всем остальным будет отказано в каких-либо операциях. Чтобы не применять ограничительную политику строки к другим пользователям, должна быть определена другая политика, чтобы разрешить другим пользователям и ролям иметь обычный или другой тип доступа.

Проверка​

Проверка привилегий ролей с пользователем с ограничениями по колонкам​

  1. Войдите в клиент ClickHouse с использованием пользователя clickhouse_admin

  2. Проверьте доступ к базе данных, таблице и всем строкам с администраторским пользователем.

  3. Войдите в клиент ClickHouse с использованием пользователя column_user

  4. Проверьте SELECT, используя все колонки

    примечание

    Доступ запрещен, так как были указаны все колонки, а у пользователя есть доступ только к id и column1

  5. Проверьте запрос SELECT с указанием только разрешенных колонок:

Проверка привилегий ролей с пользователем с ограничениями по строкам​

  1. Войдите в клиент ClickHouse, используя row_user

  2. Посмотреть доступные строки

    примечание

    Убедитесь, что возвращены только указанные выше две строки, строки со значением B в column1 должны быть исключены.

Модификация пользователей и ролей​

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

Например, если одна role1 разрешает только выбор в column1, а role2 разрешает выбор в column1 и column2, то у пользователя будет доступ к обоим колонкам.

  1. Используя учетную запись администратора, создайте нового пользователя для ограничения как по строкам, так и по колонкам с по умолчанию назначенными ролями

  2. Удалите предыдущие привилегии для роли A_rows_users

  3. Разрешите роли A_row_users выбирать только из column1

  4. Войдите в клиент ClickHouse, используя row_and_column_user

  5. Проверьте с использованием всех колонок:

  6. Проверьте с использованием ограниченных разрешенных колонок:

Устранение неполадок​

Иногда привилегии пересекаются или комбинируются, чтобы произвести неожиданные результаты, следующие команды могут быть использованы для уточнения проблемы с использованием учетной записи администратора

Список привилегий и ролей для пользователя​

Список ролей в ClickHouse​

Отображение политик​

Просмотр, как была определена политика и текущие привилегии​

Примеры команд для управления ролями, политиками и пользователями​

Следующие команды могут использоваться для:

  • удаления привилегий
  • удаления политик
  • отмены назначения пользователей на роли
  • удаления пользователей и ролей
подсказка

Запускайте эти команды как пользователь администратора или пользователь default

Удаление привилегии из роли​

Удаление политики​

Аннулирование назначения пользователя с роли​

Удаление роли​

Удаление пользователя​

Резюме​

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