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

Общие запросы управления доступом

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

Если вы работаете с самоуправляемым 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 пользователей и ролей, а также представлены шаги по установке и изменению привилегий для пользователей и ролей. Для более подробной информации по каждому пункту, пожалуйста, обратитесь к нашим руководствам пользователей и справочной документации.