Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs
49.6kGet Started

Управление сервисными учетными записями базы данных

View as MarkdownEdit this pageReport an issueSet up docs MCP

Сервисные учетные записи базы данных могут представлять собой просто пользователя с отдельным паролем или сертификатом для authentication. Более опытные пользователи могут настроить учетные записи, в которых набор разрешений можно динамически изменять с помощью SET ROLE, чтобы быстро переключаться между профилями без выхода из системы и перезагрузки содержимого.

Обзор

SET ROLE можно использовать, чтобы динамически ограничивать разрешения сервисной учетной записи в рамках сеанса. Это работает так: фактические разрешения пользователя ограничиваются только теми, которые выданы активированной роли или ролям. У этого подхода есть несколько преимуществ:

  • Сервисной учетной записи можно назначить несколько ролей, но активировать только ту, которая нужна для конкретного запроса.
  • Если сервисная учетная запись скомпрометирована, злоумышленники смогут использовать только разрешения активной роли.
  • Одна учетная запись может выполнять разные задачи, переключая роли, вместо того чтобы использовать отдельные учетные данные для каждой задачи.
  • Разрешения можно обновить для целого класса сервисных учетных записей, изменив одну роль, а не обновляя отдельных пользователей.
  • Журналы могут отслеживать, какая именно роль была активна во время запроса, что дает более ясный контекст для аудита безопасности.

На практике вы:

  1. Проектируете роли, задающие допустимые границы (read_only, maintenance и т. д.)
  2. Выдаете их сервисной учетной записи
  3. При установлении соединения выбираете активную роль или роли через SET ROLE (или параметр роли), тем самым ограничивая возможности этого сеанса

Настройте сервисную роль

Выдайте роли сервисной учетной записи

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

CREATE ROLE read_only_role;
GRANT SELECT ON db1.* TO read_only_role;

CREATE ROLE maint_role;
GRANT SELECT, INSERT, ALTER on db1.* TO maint_role;

GRANT read_only_role, maint_role TO service_user;

Используйте SET ROLE, чтобы определить границы сеанса

В начале сеанса сервисная учетная запись выбирает, какие роли будут активны:

-- Только режим "только для чтения" для этого сеанса
SET ROLE read_only_role;

или:

-- Использовать все выданные роли (полные права)
SET ROLE ALL;

SET ROLE активирует роли для текущего пользователя; итоговые привилегии — это объединение всех активных ролей и привилегий, напрямую выданных пользователю.

Вы также можете деактивировать все роли:

SET ROLE NONE;

или активировать несколько ролей:

SET ROLE read_only_role, maint_role;

Текущие активные роли можно посмотреть в system.current_roles.

Задайте роли по умолчанию для сервисной учетной записи

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

SET DEFAULT ROLE read_only_role TO service_user;

или

SET DEFAULT ROLE ALL EXCEPT maint_role TO service_user;

Использование SET ROLE по HTTP / программно

Если сервисная учетная запись подключается по HTTP, вы не можете отправить SET ROLE; SELECT ... как многооператорный запрос. Вместо этого передайте роль как query parameter:

curl "https://host:8123?user=service_user&password=...&role=read_only_role" \
 --data-binary "SELECT * FROM db1.table1"

?role=… эквивалентно выполнению SET ROLE read_only_role перед оператором. Несколько параметров роли работают так же, как SET ROLE role 1, role 2.

Некоторые драйверы (например, ClickHouse Connect for Python) также поддерживают настройку роли, которая отправляется с каждым запросом и используется сервером как роль сеанса.

Navigation