Аутентификация и авторизация¶

Эта тема даёт целостные рекомендации по лучшим практикам при разработке собственного контура аутентификации и авторизации.

Подробные инструкции по отдельным операциям см. по ссылкам в See Also.

Реальный сценарий в enterprise¶

Крупные организации часто имеют сложную структуру и множество сотрудников, использующих различные платформы и инструменты. С точки зрения IT‑governance единая система идентификации, аутентификации и авторизации даёт серьёзные преимущества:

• Упрощённое управление пользователями: администраторам не нужно вручную создавать/удалять пользователей и назначать права в разных системах. Управление жизненным циклом пользователей (например, онбординг/оффбординг) становится бесшовным и удобным для аудита.

• Повышенная безопасность: механизм Single Sign‑On (SSO) избавляет пользователей от управления несколькими учётными данными, уменьшая поверхность атаки.

• Доступ, выравненный по ролям: права доступа обычно привязаны к роли или отделу пользователя. Хорошо структурированная система идентификации упрощает и повышает точность решений по авторизации.

Пример¶

Предположим, в SaaS‑компанию приходят три новых сотрудника в разные отделы: один Marketing Specialist и двое Solution Architect.

• Организационно они в разных командах.

• С точки зрения идентификации их e‑mail‑аккаунты служат учётными данными для входа на внутренних платформах.

• По правам доступа каждому предоставлен доступ к разным платформам:

  • Marketing Specialist может входить в бэкенд Hubspot для просмотра лидов.

  • Solution Architect имеют доступ к service console и управляют сервисами закреплённых клиентов.

Несмотря на использование одного identity provider, их права строго разграничены:

• Marketing Specialist имеет доступ только к Hubspot.

• Solution Architect могут входить в service console, но не к сервисам пользователей, за которых они не отвечают. Доступа к Hubspot у них нет.

Три слоя контроля доступа¶

Этот пример подчёркивает три ключевых компонента в потоке корпоративной идентификации и доступа:

1. Identity Authentication — «Я Питер, подтверждённый сотрудник компании SaaS».

2. Access Authentication — «Как Solution Architect, я авторизован для входа в service console». (Не все подтверждённые сотрудники должны иметь доступ ко всем сервисам.)

3. Action Authorization — «Как клиент компании SaaS, я могу видеть информацию только по нашему сервису, но не по чужим».

В контексте базы данных¶

Эти слои применимы и к СУБД:

1. Проверка личности: подтверждение, что пользователь — действительный сотрудник со своим паролем.

2. Доступ к кластеру: проверка, что пользователь или его группа имеют право логина в конкретный кластер.

3. Авторизация операций: проверка, может ли пользователь выполнять запросы, загрузку данных и т. п.

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

Ключевые понятия¶

LDAP¶

Lightweight Directory Access Protocol (LDAP) — протокол доступа и управления распределённой справочной информацией. Его можно воспринимать как «глобальную адресную книгу» организации:

• У каждого пользователя есть уникальный путь (Distinguished Name, DN).

• LDAP хранит базовую информацию о пользователе, включая пароли.

• LDAP управляет группами и членством в них.

• С помощью ldapsearch можно получать пользователей или группы.

LDAP можно использовать:

• как источник аутентификации (проверка логина и пароля);

• как поставщик информации о группах для контроля доступа.

Возможности¶

Система поддерживает все три слоя контроля доступа:

1. User Authentication — «Я — это действительно я».

2. Login Authorization — «Мне разрешён доступ к этому кластеру» (зависит от пользователя или членства в группах).

3. Operation Authorization — «Я могу выполнить этот запрос или загрузить этот датасет» (авторизация может основываться на идентичности или группе).

Начиная с v3.5, StarRocks предоставляет модульную, компонуемую модель для различных комбинаций компонентов IAM.

Feature Mapping

Аутентификация¶

Сравнение поддерживаемых режимов аутентификации:

Эти режимы могут сосуществовать. Когда пользователь пытается войти:

1. Кластер сначала проверяет, существует ли пользователь как native user, и пытается аутентифицировать его соответствующим образом.

2. Если пользователь не найден, кластер следует вниз по authentication_chain, заданной в конфигурации.

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

Вариант 1: Создать Native User с внешней аутентификацией¶

Например, можно создать native user с LDAP:

CREATE USER <username> IDENTIFIED WITH authentication_ldap_simple AS 'uid=tom,ou=company,dc=example,dc=com';

Затем выполните GRANT привилегий или ролей пользователю, либо делегируйте авторизацию внешним системам, таким как Apache Ranger.

Вариант 2: Security Integration с внешней аутентификацией¶

Можно создать security integration для допуска кластера к внешней службе аутентификации:

CREATE SECURITY INTEGRATION <security_integration_name> 
PROPERTIES (
    "type" = "authentication_ldap_simple",
    "authentication_ldap_simple_server_host" = "",
    "authentication_ldap_simple_server_port" = "",
    "authentication_ldap_simple_bind_base_dn" = "",
    "authentication_ldap_simple_user_search_attr" = ""
    "authentication_ldap_simple_bind_root_dn" = "",
    "authentication_ldap_simple_bind_root_pwd" = "",
    "authentication_ldap_simple_ssl_conn_allow_insecure" = "{true | false}",
    "authentication_ldap_simple_ssl_conn_trust_store_path" = "",
    "authentication_ldap_simple_ssl_conn_trust_store_pwd" = "",
    "comment" = ""
);

После этого необходимо настроить параметр FE authentication_chain и включить созданную security integration для кластера.

ADMIN SET FRONTEND CONFIG (
    "authentication_chain" = "<security_integration_name>[... ,]"
);

Group Provider (необязателен, но рекомендован)¶

Информация о группах в кластере развязана как с аутентификацией, так и с авторизацией. Это общий слой, который можно настраивать независимо и использовать и для контроля логина, и для контроля доступа.

Как используются группы¶

• На этапе аутентификации

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

• На этапе авторизации

  Членство в группах учитывается автоматически. Если привилегии выданы группе, все её участники унаследуют права при проверке доступа.

Примечания по конфигурации¶

• При настройке group provider следует указать:

  • Группы, определяющие кто может логиниться (login scope)

  • Группы, определяющие кто имеет доступ к конкретным ресурсам (authorization)

• Важно: идентичность пользователя (например, имя или ID), возвращаемая group provider, должна совпадать с идентичностью, используемой на этапах аутентификации и авторизации. Несоответствие приведёт к ошибкам входа или прав.

Пример¶

Ниже — пример на основе LDAP.

1. Создайте group provider.

   -- LDAP Group Provider
   CREATE GROUP PROVIDER <group_provider_name> 
   PROPERTIES (
       "type" = "ldap",
       ldap_info,
       ldap_search_group_arg,
       ldap_search_attr,
       [ldap_cache_attr]
   )
   
   ldap_info ::=
       "ldap_conn_url" = "",
       "ldap_bind_root_dn" = "",
       "ldap_bind_root_pwd" = "",
       "ldap_bind_base_dn" = "",
       ["ldap_conn_timeout" = "",]
       ["ldap_conn_read_timeout" = ""]
   
   ldap_search_group_arg ::= 
       { "ldap_group_dn" = "" 
       | "ldap_group_filter" = "" }, 
       "ldap_group_identifier_attr" = ""
   
   ldap_search_user_arg ::=
       "ldap_group_member_attr" = "",
       "ldap_user_search_attr" = ""
   
   ldap_cache_arg ::= 
       "ldap_cache_refresh_interval" = ""
   

2. Интегрируйте group provider с security integration.

   ALTER SECURITY INTEGRATION <security_integration_name> SET
   (
       "group_provider" = "",
       "permitted_groups" = ""
   )
   

3. Интегрируйте group provider с системой авторизации. Можно использовать нативную авторизацию или Apache Ranger.

   • Нативная авторизация:

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

     GRANT role TO EXTERNAL GROUP <group_name>
     

   • Apache Ranger:

     После входа StarRocks передаёт информацию о группах в Ranger для оценки политик.

Авторизация¶

StarRocks поддерживает как внутренние, так и внешние механизмы авторизации, их можно использовать независимо или комбинировать:

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

  Встроенные RBAC (Role‑Based Access Control) и IBAC (Identity‑Based Access Control).

  • RBAC: роли назначаются пользователям или группам, а привилегии — ролям.

  • IBAC: привилегии выдаются напрямую пользователям.

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

  Интеграция с Apache Ranger для централизованного и унифицированного управления доступом.

Apache Ranger можно использовать как в полном объёме, так и совместно с нативной авторизацией StarRocks.

• Полная авторизация в Ranger: и внутренние, и внешние таблицы (например, Hive) авторизуются через Ranger.

  • Права на внутренние таблицы — через StarRocks plugin для Ranger.

  • Права на внешние таблицы — через StarRocks plugin или плагины внешних сервисов (например, Hive plugin).

• Гибридная авторизация

  • Внутренние таблицы: авторизация нативной системой StarRocks (RBAC/IBAC).

  • Внешние таблицы: авторизация через Ranger; права могут управляться через StarRocks plugin или соответствующий внешний сервис (например, Hive, HDFS).

Эта гибкость позволяет постепенно мигрировать к централизованной авторизации или поддерживать гибридную модель в соответствии с текущей инфраструктурой и политиками безопасности.

Комбинированные решения¶

Выберите подход на основе желаемого сценария аутентификации и авторизации.

Решение 1: Внешняя аутентификация + внешняя авторизация¶

Можно полностью использовать внешние системы для управления логином и правами доступа к кластеру. Общая схема:

1. Примените security integration для связи с внешней аутентификацией.

2. Настройте необходимые групповые сведения для аутентификации и авторизации в group provider.

3. Определите в security integration группы, которым разрешён вход в кластер. Пользователи из этих групп смогут входить.

4. Создайте StarRocks service в Apache Ranger для управления доступом как к внутренним, так и к внешним таблицам. Для внешних таблиц можно переиспользовать существующие сервисы.

5. При выполнении запроса система отправляет в Ranger идентичность пользователя и его группы (как настроено в group provider) для авторизации.

6. При успешной проверке выполняется запрос.

Решение 2: Внешняя аутентификация (Native User) + внутренняя авторизация¶

Если вы хотите использовать встроенную систему авторизации, полагаясь при этом на внешнюю аутентификацию:

1. Создавайте пользователей вручную и указывайте для каждого внешний метод аутентификации.

2. После создания назначайте роли или привилегии стандартными командами GRANT.

3. После аутентификации пользователь авторизуется нативной системой прав кластера.

Решение 3: Внешняя аутентификация (внешняя идентичность) + внутренняя авторизация¶

Если вы хотите использовать встроенную авторизацию StarRocks, опираясь на внешнюю аутентификацию:

1. Настройте security integration для связи с внешней аутентификацией.

2. Настройте необходимые групповые сведения в group provider.

3. В security integration определите группы, которым разрешён вход в кластер StarRocks.

4. Создайте необходимые роли в StarRocks и выдайте их внешним группам.

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

6. Во время выполнения запросов StarRocks как обычно применяет внутреннюю RBAC‑авторизацию.

7. Дополнительно можно комбинировать с Ranger: например, для внутренних таблиц — нативный RBAC, для внешних — Ranger. При авторизации через Ranger StarRocks всё равно передаст user ID и информацию о группах в Ranger для контроля доступа.