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

Подключаемые механизмы аутентификации и авторизации

Кратко Apache Doris отделяет идентификацию пользователя (кто вы) от политик доступа (что вам разрешено), позволяя менять бэкенд каждой из этих подсистем без создания форка FE. При рукопожатии MySQL вызывается Authenticator, выбранный параметром authentication_type: встроенная проверка пароля, LDAP или любой плагин, обнаруженный через Java SPI. Авторизация выполняется через CatalogAccessController, выбранный параметром access_controller_type: встроенный механизм RBAC или Apache Ranger для централизованного управления политиками. Задайте конфигурацию, добавьте jar-файл плагина, перезапустите сервис, и всё готово.

Подключаемые механизмы аутентификации и авторизации Apache Doris: меняйте бэкенды идентификации и политик доступа Doris без создания форка FE. Выбирайте LDAP, Kerberos, OIDC или Ranger через конфигурацию и настраивайте цепочки резервных механизмов.

Зачем использовать подключаемые механизмы аутентификации и авторизации в Apache Doris?​

Подключаемые механизмы аутентификации и авторизации Apache Doris позволяют передать управление пользователями и политиками доступа к хранилищу данных существующей инфраструктуре IAM (LDAP, Kerberos, OIDC, Ranger), чтобы команде платформы не приходилось вести отдельный список пользователей. Большинство команд начинают работать с Doris, уже имея инфраструктуру IAM. У них есть каталог LDAP, область Kerberos, провайдер OIDC для SSO и развернутая система Ranger или Sentry, управляющая правами доступа к Hive. Если хранилище данных игнорирует эту инфраструктуру, команде платформы приходится вести отдельный список пользователей, синхронизировать пароли скриптами и объяснять аудиторам, почему в истории запросов пользователи обозначены иначе, чем в остальных компонентах lakehouse. Используйте единую идентификацию вместе с федерацией multi-catalog и отслеживанием происхождения данных, чтобы записи аудита были согласованы во всем озере данных.

Apache Doris предоставляет точки подключения плагинов как для аутентификации, так и для авторизации. Бэкенды аутентификации обнаруживаются через Java SPI; тот же механизм используется для бэкендов авторизации. Для перехода с локальных паролей на LDAP достаточно одной строки конфигурации. Переход со встроенного RBAC на Ranger задается другой строкой. Эти решения независимы: плагин OIDC можно использовать вместе с Ranger, а LDAP вполне сочетается со встроенным RBAC.

  • Единый IdP для всей платформы данных вместо отдельного списка пользователей Doris.
  • Централизованные политики в Ranger, который уже управляет доступом к Hive, HDFS и Iceberg; Doris подключается к тому же сервису.
  • Собственная аутентификация (проприетарные форматы токенов, проверка паролей с учетом арендатора) без изменения исходного кода FE.

Что представляют собой подключаемые механизмы аутентификации и авторизации Apache Doris?​

Подключаемые механизмы аутентификации и авторизации Apache Doris реализованы как две расположенные рядом точки расширения на FE. Первая — интерфейс Authenticator, который вызывается один раз при каждом рукопожатии MySQL и преобразует учетные данные из пакета аутентификации в UserIdentity. Вторая — интерфейс CatalogAccessController, который вызывается при каждом запросе и проверяет, разрешен ли этому пользователю доступ к каталогу, базе данных, таблице или столбцу. Оба механизма загружаются через java.util.ServiceLoader, поэтому сторонний jar-файл, добавленный в classpath, регистрируется автоматически.

Основные термины

  • authentication_type: параметр конфигурации FE, выбирающий основной механизм аутентификации. Встроенные значения — default (псевдоним password) и ldap; любая другая строка интерпретируется как имя плагина.
  • authentication_chain: разделенный запятыми список резервных механизмов аутентификации, которые проверяются после отказа основного. Полезен для сохранения локальных пользователей аварийного доступа, когда обычные входы обрабатываются через LDAP или OIDC.
  • access_controller_type: параметр конфигурации FE, выбирающий механизм авторизации для внутреннего каталога. Значение default сохраняет встроенный RBAC; ranger-doris передает каждую проверку плагину Ranger.
  • AuthenticatorFactory / AccessControllerFactory: точки расширения SPI, перечисленные в META-INF/services. Реализуйте одну из них, чтобы добавить новый бэкенд.
  • Механизм авторизации внешнего каталога: каждый внешний каталог (Hive, Iceberg) может выбирать собственный контроллер, поэтому каталог Hive может использовать существующие политики Ranger Hive, а внутренний каталог — Doris RBAC.

Как работают подключаемые механизмы аутентификации и авторизации Apache Doris?​

Подключаемые механизмы аутентификации и авторизации Apache Doris используют две независимые цепочки SPI: Authenticator преобразует результат рукопожатия MySQL в UserIdentity, после чего отдельный для каждого каталога CatalogAccessController проверяет каждый оператор, включая фильтры строк и маскирование столбцов.

  1. Выбор механизма аутентификации при запуске. AuthenticatorManager считывает authentication_type, нормализует значение и находит соответствующую реализацию через ServiceLoader<AuthenticatorFactory>. Встроенные фабрики (DefaultAuthenticatorFactory, LdapAuthenticatorFactory) поставляются в jar-файле FE; пользовательские фабрики размещаются в fe/plugins/. Если подходящая фабрика прежнего механизма не найдена, менеджер переходит к AuthenticationPluginAuthenticator, который обрабатывает OIDC, OAuth2 и JWT.
  2. Аутентификация соединения. Когда клиент открывает соединение MySQL, выбранный механизм аутентификации анализирует рукопожатие. Встроенная проверка пароля сравнивает скремблированный хеш, LDAP выполняет привязку к каталогу, а OIDC проверяет JWT и извлекает из него claims. При успехе возвращается UserIdentity; при отказе — причина с указанием типа.
  3. Проверка цепочки при отказе. Если задан параметр authentication_chain, менеджер последовательно запускает перечисленные механизмы аутентификации. Типичная конфигурация — authentication_type = ldap вместе с authentication_chain = default: администраторы сохраняют доступ по локальному паролю даже при недоступности LDAP.
  4. Передача управления механизму авторизации. После привязки пользователя к сеансу каждый оператор проходит через AccessControllerManager. Внутренний каталог использует механизм, выбранный параметром access_controller_type. Внешний каталог использует механизм, выбранный свойством каталога access_controller.class, поэтому в одном кластере можно сочетать Doris RBAC для внутреннего каталога с Ranger для каталога Hive.
  5. Проверка политик строк и столбцов. Тот же контроллер предоставляет точки расширения для маскирования столбцов и фильтрации строк. Встроенный RBAC считывает политики, сохраненные с помощью CREATE ROW POLICY. Контроллер Ranger вызывает evalRowFilterPolicies и evalDataMaskPolicy у плагина Ranger, поэтому к запросам Doris применяются те же правила маскирования, что и в Hive.

Быстрый старт​

# fe.conf: enable LDAP for everyone, keep local passwords as fallback
authentication_type = ldap
authentication_chain = default
access_controller_type = ranger-doris
-- Roles in Doris match LDAP group names; Ranger holds the actual grants
CREATE ROLE doris_analyst;
CREATE ROLE doris_etl;

-- Local break-glass account that survives LDAP / Ranger outages
CREATE USER 'breakglass'@'127.0.0.1' IDENTIFIED BY 'rotate-me';
GRANT 'admin' TO 'breakglass'@'127.0.0.1';

Ожидаемый результат

mysql> SELECT current_user(), user();
+---------------------+----------------------+
| current_user()      | user()               |
+---------------------+----------------------+
| jdoe@'%'            | jdoe@'10.0.4.21'     |
+---------------------+----------------------+

Пользователь jdoe вошел с паролем LDAP и получил роль doris_analyst через сопоставление групп LDAP, а каждый последующий SELECT проверяется по политике Ranger, привязанной к сервису doris.

Когда стоит использовать подключаемые механизмы аутентификации и авторизации Apache Doris?​

Используйте подключаемые механизмы аутентификации и авторизации Apache Doris, когда управлять пользователями хранилища данных должен существующий IdP или сервис политик, а FE должен лишь принимать учетные данные и решения о доступе.

Подходящие сценарии

  • Организации, которые уже используют IdP (LDAP, AD, OIDC, Kerberos KDC) и хотят подключить к нему Doris, чтобы не вести отдельный список пользователей.
  • Развертывания lakehouse, в которых Ranger уже используется для Hive, HDFS или Iceberg и требуется применять те же политики к таблицам под управлением Doris. См. Авторизация Ranger.
  • Многоарендные SaaS-системы, в которых каждый арендатор использует собственного провайдера идентификации через пользовательскую реализацию AuthenticatorFactory.
  • Команды, которым для SSO из BI-инструментов нужны рукопожатия с передачей учетных данных в открытом виде или на основе токенов (OIDC, JWT), с обязательным использованием TLS на стороне Doris.

Неподходящие сценарии

  • Изолированные кластеры без доступа к LDAP, KDC или Ranger Admin. Плагин будет продолжать повторные попытки подключения, а запросы будут тратить время на сетевой обмен. Используйте встроенный RBAC и локальные учетные записи.
  • Короткие запросы с жесткими требованиями к задержке, для которых существенны затраты на проверку политик Ranger при каждом запросе. Ranger кеширует политики локально, и обращение к кешу требует мало ресурсов, но первый запрос после обновления политик создает дополнительные издержки.
  • Бэкенды, для которых Doris пока не предоставляет встроенную фабрику. Аутентификация Kerberos / GSSAPI для самого рукопожатия MySQL не входит в поставку. Сервер Ranger Admin может быть защищен Kerberos, но для соединения между FE и клиентом нужен токен OIDC или привязка LDAP. Если требуется такая поддержка, напишите собственную реализацию AuthenticatorFactory.
  • Совместное использование Ranger и операторов GRANT для одного внутреннего каталога. После включения access_controller_type = ranger-doris встроенный RBAC перестает принимать изменения. Выберите единый источник правил и придерживайтесь его.

Дополнительные материалы​

  • Обзор аутентификации и авторизации: полная концептуальная модель, включая идентификацию пользователей, роли и правила приоритета, определяющие, под каким пользователем устанавливается соединение.
  • Встроенная аутентификация: политики паролей, срок действия, блокировка и правила сложности validate_password_policy.
  • Аутентификация LDAP: справочник по ldap.conf, сопоставление групп с ролями, настройка LDAPS и порядок настройки плагина передачи пароля в открытом виде для клиентов MySQL и JDBC.
  • Авторизация Ranger: установка плагина Doris Ranger, примеры политик для каталогов, баз данных, таблиц и столбцов, а также работа фильтрации строк и маскирования.
  • Обзор безопасности: общая картина, включая журналы аудита, передачу данных по SSL и рекомендации по UDF.
  • Multi-Catalog: как авторизация в стиле Ranger подключается к отдельным контроллерам доступа каталогов Hive, Iceberg и других внешних источников.
Report issue