Встроенная авторизация

Встроенная авторизация Doris основана на модели RBAC (Role-Based Access Control). Трёхуровневая структура «привилегия → роль → пользователь» ограничивает доступ каждого пользователя к таким ресурсам, как узлы, Catalog, базы данных, таблицы, столбцы, Resource и Workload Group, а также операции с ними в зависимости от идентификационных данных пользователя.

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

Сценарии применения

Сценарий	Рекомендуемый подход
Эксплуатация кластера (администратор)	Предоставьте Admin_priv или Node_priv и используйте встроенные роли operator / admin
Разработка для работы с данными (создание баз данных и таблиц, загрузка данных)	Предоставьте привилегии CREATE, DROP, ALTER, LOAD, SELECT для указанных баз данных и таблиц
Запросы к данным (доступ только для чтения)	Предоставьте Select_priv для указанных баз данных, таблиц и столбцов
Общий кластер для нескольких направлений бизнеса и арендаторов	Для базы данных каждого направления создайте пользователя «администратор направления» с привилегией Grant_priv на уровне базы данных и поручите ему управление пользователями своего направления
Изоляция Resource / рабочей нагрузки	Управляйте использованием Resource и Workload Group с помощью Usage_priv
Защита конфиденциальных полей (например, номера телефона или удостоверения личности)	Используйте Select_priv на уровне столбцов или сочетайте эту привилегию с управлением доступом к данным для настройки политик на уровне строк

Основные понятия

Авторизация Doris включает три основные сущности:

• Привилегия: разрешение на выполнение операции с определённым объектом ресурса (например, чтение, запись, изменение).
• Роль: набор привилегий, который можно назначать пользователям.
• Пользователь: инициатор операции, однозначно определяемый сочетанием user_name и host.

Привилегия

Привилегии распространяются на такие объекты, как узлы, Catalog, базы данных, таблицы, столбцы, Resource и Workload Group. Разные привилегии разрешают разные операции.

Все виды привилегий

Привилегия	Тип объекта	Описание
Admin_priv	Глобальный уровень	Привилегия суперадминистратора.
Node_priv	Глобальный уровень	Привилегия изменения узлов. Включает такие операции, как добавление, удаление и вывод из эксплуатации узлов FE, BE и BROKER.
Grant_priv	Глобальный уровень, Catalog, база данных, таблица, Resource, Workload Group	Привилегия изменения прав доступа. Разрешает предоставлять и отзывать привилегии, а также добавлять, удалять и изменять пользователей и роли. При предоставлении привилегий другим пользователям или ролям: до версии 2.1.2 текущему пользователю достаточно иметь Grant_priv соответствующего уровня; начиная с версии 2.1.2 текущий пользователь также должен обладать предоставляемой привилегией на соответствующий ресурс. Для назначения роли другим пользователям текущий пользователь должен обладать Grant_priv глобального уровня.
Select_priv	Глобальный уровень, Catalog, база данных, таблица, столбец	Привилегия доступа только для чтения к Catalog, базам данных, таблицам и столбцам.
Load_priv	Глобальный уровень, Catalog, база данных, таблица	Привилегия записи в Catalog, базы данных и таблицы. Включает Load, Insert, Delete и другие операции.
Alter_priv	Глобальный уровень, Catalog, база данных, таблица	Привилегия изменения Catalog, баз данных и таблиц. Включает переименование баз данных и таблиц, добавление, удаление и изменение столбцов, а также добавление и удаление разделов.
Create_priv	Глобальный уровень, Catalog, база данных, таблица	Привилегия создания Catalog, баз данных, таблиц и представлений.
Drop_priv	Глобальный уровень, Catalog, база данных, таблица	Привилегия удаления Catalog, баз данных, таблиц и представлений.
Usage_priv	Resource, Workload Group	Привилегия использования Resource и Workload Group.
Show_view_priv	Глобальный уровень, Catalog, база данных, таблица	Привилегия выполнения SHOW CREATE VIEW.

Уровни привилегий

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

Уровень	Пример пути при предоставлении привилегии	Область действия
Глобальный	GRANT ... ON *.*.* TO user1	Любая база данных или таблица в любом Catalog
Catalog	GRANT ... ON ctl.*.* TO user1	Любая база данных или таблица в указанном Catalog
База данных	GRANT ... ON ctl.db.* TO user1	Любая таблица в указанной базе данных
Таблица	GRANT ... ON ctl.db.tbl TO user1	Любой столбец в указанной таблице
Столбец	GRANT Select_priv(col1,col2) ON ctl.db.tbl TO user1	Указанные столбцы указанной таблицы; на уровне столбцов в настоящее время поддерживается только Select_priv
Строка	Определяется политиками, см. Управление доступом к данным	Определяет строки данных, доступные пользователю
Resource	GRANT USAGE_PRIV ON RESOURCE '%' TO user1	Использование Resource; поддерживаются только Usage_priv и Grant_priv
Workload Group	GRANT USAGE_PRIV ON WORKLOAD GROUP '%' TO user1	Использование Workload Group; поддерживаются только Usage_priv и Grant_priv

подсказка

Admin_priv можно предоставлять и отзывать только на глобальном уровне.

Роль

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

Встроенные роли

По умолчанию Doris создаёт две встроенные роли:

Встроенная роль	Привилегии по умолчанию	Типовое применение
operator	Admin_priv + Node_priv	Эксплуатация кластера, изменение узлов
admin	Admin_priv	Управление бизнесом и данными

Пользовательские роли

С помощью CREATE ROLE можно создавать именованные роли, объединять в них часто используемые привилегии и назначать их сразу нескольким пользователям. Это упрощает централизованное управление и отзыв привилегий.

Пользователь

В Doris пользователь однозначно определяется с помощью user_identity. Значение user_identity состоит из двух частей:

• user_name: имя пользователя.
• host: адрес хоста, с которого подключается клиент пользователя.

Механизм авторизации

Система привилегий Doris основана на модели RBAC. Пользователи связаны с ролями, а роли связаны с привилегиями. Пользователь получает привилегии опосредованно, через роли.

┌────────┐        ┌────────┐         ┌────────┐
│  user1 ├────┬───►  role1 ├────┬────►  priv1 │
└────────┘    │   └────────┘    │    └────────┘
              │                 │
              │                 │
              │   ┌────────┐    │
              │   │  role2 ├────┤
┌────────┐    │   └────────┘    │    ┌────────┐
│  user2 ├────┘                 │  ┌─►  priv2 │
└────────┘                      │  │ └────────┘
                  ┌────────┐    │  │
           ┌──────►  role3 ├────┘  │
           │      └────────┘       │
           │                       │
           │                       │
┌────────┐ │      ┌────────┐       │ ┌────────┐
│  userN ├─┴──────►  roleN ├───────┴─►  privN │
└────────┘        └────────┘         └────────┘

Как показано на схеме выше:

• Пользователи user1 и user2 обладают привилегией priv1 через роль role1.
• Пользователь userN обладает привилегией priv1 через роль role3 и получает привилегии priv2 и privN через роль roleN. Таким образом, пользователь userN одновременно обладает привилегиями priv1, priv2 и privN.

Правила наследования и отзыва привилегий

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

Примечания

• Для удобства Doris поддерживает предоставление привилегий непосредственно пользователям. Во внутренней реализации для каждого пользователя создаётся отдельная роль по умолчанию. Предоставление привилегий непосредственно пользователю фактически означает их предоставление этой роли по умолчанию.
• Роль по умолчанию нельзя удалить или назначить другим пользователям. При удалении пользователя его роль по умолчанию также удаляется автоматически.

Связанные команды SQL

Категория операции	Команда
Предоставление привилегий / назначение роли	GRANT
Отзыв привилегий / снятие роли	REVOKE
Создание роли	CREATE ROLE
Удаление роли	DROP ROLE
Изменение роли	ALTER ROLE
Просмотр привилегий текущего пользователя	SHOW GRANTS
Просмотр привилегий всех пользователей	SHOW ALL GRANTS
Просмотр созданных ролей	SHOW ROLES
Просмотр всех поддерживаемых видов привилегий	SHOW PRIVILEGES

Рекомендуемые практики

Ниже приведены два типовых сценария использования системы привилегий Doris.

Сценарий 1: распределение обязанностей на основе ролей в кластере для одного направления бизнеса

Пользователи кластера Doris делятся на администраторов (Admin), инженеров-разработчиков (RD) и клиентов (Client):

• Администратор: обладает всеми привилегиями во всём кластере и отвечает за развёртывание кластера, управление узлами и другие подобные задачи.
• Инженер-разработчик (RD): отвечает за моделирование данных для бизнеса, включая создание баз данных и таблиц, загрузку и изменение данных.
• Клиент: обращается к различным базам данных и таблицам для получения данных.

Рекомендуемая схема авторизации:

• Администратор: предоставьте Admin_priv или глобальную привилегию Grant_priv.
• RD: предоставьте Create_priv, Drop_priv, Alter_priv, Load_priv и Select_priv для любых или указанных баз данных и таблиц.
• Клиент: предоставьте Select_priv для любых или указанных баз данных и таблиц.

Для упрощения массового предоставления привилегий нескольким пользователям можно создать разные роли.

Сценарий 2: делегированное управление в кластере для нескольких направлений бизнеса

Один кластер обслуживает несколько направлений бизнеса. Каждое направление использует одну или несколько баз данных и должно самостоятельно управлять своими пользователями.

Рекомендуемая схема авторизации: администратор создаёт для базы данных каждого направления пользователя «администратор направления» и предоставляет ему Grant_priv на уровне соответствующей базы данных. Этот пользователь может предоставлять привилегии другим пользователям только в пределах базы данных, к которой ему предоставлен доступ. Это обеспечивает изоляцию привилегий и самостоятельное управление для каждого направления бизнеса.