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

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

Система управления правами доступа Doris построена по образцу механизма управления правами MySQL. Она поддерживает детальное управление правами на уровне строк и столбцов, управление доступом на основе ролей, а также механизм белого списка.

Глоссарий​

  1. Идентификатор пользователя

    В системе управления правами пользователь представлен идентификатором пользователя (User Identity). Идентификатор пользователя состоит из двух частей: username и host. Часть username — это имя пользователя, состоящее из латинских букв (прописных и строчных). Часть host обозначает IP-адрес, с которого пользователь устанавливает соединение. Идентификатор пользователя записывается как username@'host' и обозначает пользователя username, подключающегося с host.

    Другой вариант записи идентификатора пользователя — username@['domain'], где domain обозначает доменное имя, которое с помощью DNS можно преобразовать в набор IP-адресов. В конечном счёте такая запись представляется набором идентификаторов username@'host', поэтому далее для единообразия используется обозначение username@'host'.

  2. Право доступа

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

  3. Роль

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

  4. Свойство пользователя

    Свойства пользователя относятся непосредственно к пользователю, а не к его идентификатору. Это означает, что user@'192.%' и user@['domain'] используют один и тот же набор свойств, принадлежащих пользователю user, а не идентификатору user@'192.%' или user@['domain'].

    К свойствам пользователя относятся, в частности, максимальное количество соединений пользователя, конфигурации кластеров загрузки данных и другие параметры.

Общая схема аутентификации и авторизации​

Процесс входа пользователя в Apache Doris состоит из двух этапов: аутентификации и авторизации.

  • Аутентификация: проверка личности на основе предоставленных пользователем учётных данных (например, имени пользователя, IP-адреса клиента и пароля). После успешной проверки пользователю сопоставляется идентификатор пользователя, определённый в системе.
  • Авторизация: на основе полученного идентификатора пользователя и связанных с ним прав проверяется, разрешено ли пользователю выполнять запрашиваемые операции.

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

Doris поддерживает встроенные схемы аутентификации, а также аутентификацию через LDAP.

Встроенная схема аутентификации Doris​

Аутентификация выполняется на основе имён пользователей, паролей и других сведений, хранящихся непосредственно в Doris.

Администраторы создают пользователей командой CREATE USER и просматривают права и роли всех пользователей командой SHOW ALL GRANTS.

При входе пользователя система проверяет корректность имени пользователя, пароля и IP-адреса клиента.

Политика паролей​

Doris поддерживает следующие политики, помогающие управлять паролями.

  1. PASSWORD_HISTORY

    Определяет, может ли пользователь повторно использовать один из предыдущих паролей при смене текущего. Например, PASSWORD_HISTORY 10 означает, что последние 10 паролей нельзя использовать в качестве нового пароля. При установке PASSWORD_HISTORY DEFAULT используется значение глобальной переменной PASSWORD_HISTORY. Значение 0 отключает эту функцию. По умолчанию используется 0.

    Примеры:

    • Установка глобальной переменной: SET GLOBAL password_history = 10
    • Настройка для пользователя: ALTER USER user1@'ip' PASSWORD_HISTORY 10

  2. PASSWORD_EXPIRE

    Задаёт срок действия пароля текущего пользователя. Например, PASSWORD_EXPIRE INTERVAL 10 DAY означает, что срок действия пароля истечёт через 10 дней. Значение PASSWORD_EXPIRE NEVER указывает, что срок действия пароля не ограничен. При установке PASSWORD_EXPIRE DEFAULT используется значение глобальной переменной default_password_lifetime (в днях). По умолчанию используется NEVER (или 0), то есть срок действия не ограничен.

    Примеры:

    • Установка глобальной переменной: SET GLOBAL default_password_lifetime = 1
    • Настройка для пользователя: ALTER USER user1@'ip' PASSWORD_EXPIRE INTERVAL 10 DAY

  3. FAILED_LOGIN_ATTEMPTS и PASSWORD_LOCK_TIME

    Задают количество попыток ввода неверного пароля, после которого учётная запись блокируется, и длительность блокировки. Например, FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 DAY означает, что после 3 неудачных попыток входа учётная запись будет заблокирована на один день. Администраторы могут разблокировать учётную запись с помощью инструкции ALTER USER.

    Пример:

    • Настройка для пользователя: ALTER USER user1@'ip' FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 DAY

  4. Сложность пароля

    Управляется глобальной переменной validate_password_policy. Значение по умолчанию — NONE/0, при котором сложность пароля не проверяется. Если установлено STRONG/2, пароль должен содержать символы как минимум трёх из следующих типов: прописные буквы, строчные буквы, цифры и специальные символы. Длина пароля должна составлять не менее 8 символов.

    Пример:

    • SET validate_password_policy=STRONG

    Начиная с Doris 4.0.4, политика проверки сложности паролей расширена следующим образом:

    1. Если для validate_password_policy установлено значение STRONG/2, пароль должен содержать все 4 типа символов (прописные буквы, строчные буквы, цифры и специальные символы), тогда как ранее требовалось «3 из 4».

    2. Добавлена проверка по словарю: пароли не могут содержать распространённые слова, делающие их слабыми (например, password, admin, test, root и т. д.). В систему встроен словарь таких слов, и пароли, содержащие их, отклоняются.

    3. Добавлена поддержка пользовательских файлов словарей: имя файла собственного словаря можно задать через глобальную переменную validate_password_dictionary_file. Файл словаря необходимо разместить в каталоге ${DORIS_HOME}/plugins/security/. Формат файла — одно слово на строку; пустые строки и строки, начинающиеся с #, игнорируются.

      Пример:

      • SET GLOBAL validate_password_dictionary_file = 'my_dictionary.txt'

Дополнительные сведения см. в разделе ALTER USER.

Схема аутентификации на основе LDAP​

См. раздел Схема аутентификации на основе LDAP.

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

Операции управления правами доступа​

  • Создание пользователя: CREATE USER
  • Изменение пользователя: ALTER USER
  • Удаление пользователя: DROP USER
  • Предоставление прав / назначение роли: GRANT
  • Отзыв прав / отмена назначения роли: REVOKE
  • Создание роли: CREATE ROLE
  • Удаление роли: DROP ROLE
  • Изменение роли: ALTER ROLE
  • Просмотр прав и ролей текущего пользователя: SHOW GRANTS
  • Просмотр прав и ролей всех пользователей: SHOW ALL GRANTS
  • Просмотр созданных ролей: SHOW ROLES
  • Установка свойства пользователя: SET PROPERTY
  • Просмотр свойства пользователя: SHOW PROPERTY
  • Смена пароля: SET PASSWORD
  • Просмотр всех поддерживаемых прав: [SHOW PRIVILEGES]
  • Просмотр политики доступа к строкам: [SHOW ROW POLICY]
  • Создание политики доступа к строкам: [CREATE ROW POLICY]

Типы прав доступа​

В настоящее время Doris поддерживает следующие права доступа:

  1. Node_priv

    Право на изменение узлов. Включает добавление, удаление и вывод из эксплуатации узлов FE, BE и BROKER.

    Пользователи Root имеют это право по умолчанию. Пользователи, обладающие одновременно правами Grant_priv и Node_priv, могут предоставлять это право другим пользователям.

    Это право можно предоставить только на уровне Global.

  2. Grant_priv

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

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

    Для назначения ролей другим пользователям требуется право Grant_priv на уровне Global.

  3. Select_priv

    Право на чтение данных из каталогов данных, баз данных и таблиц.

  4. Load_priv

    Право на запись данных в каталоги данных, базы данных и таблицы. Включает операции Load, Insert, Delete и другие.

  5. Alter_priv

    Право на изменение каталогов данных, баз данных и таблиц. Включает переименование баз данных и таблиц, добавление, удаление и изменение столбцов, добавление и удаление разделов и другие операции.

  6. Create_priv

    Право на создание каталогов данных, баз данных, таблиц и представлений.

  7. Drop_priv

    Право на удаление каталогов данных, баз данных, таблиц и представлений.

  8. Usage_priv

    Право на использование Resources и Workload Groups.

  9. Show_view_priv

    Право на выполнение SHOW CREATE VIEW.

Уровни прав доступа​

Глобальные права​

Права, предоставленные инструкцией GRANT с областью действия *.*.*. Эти права распространяются на любую таблицу в любом Catalog.

Права на Catalog​

Права, предоставленные инструкцией GRANT с областью действия ctl.*.*. Эти права распространяются на любую таблицу в указанном Catalog.

Права на базу данных​

Права, предоставленные инструкцией GRANT с областью действия ctl.db.*. Эти права распространяются на любую таблицу в указанной базе данных.

Права на таблицу​

Права, предоставленные инструкцией GRANT с областью действия ctl.db.tbl. Эти права распространяются на любой столбец указанной таблицы.

Права на столбцы​

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

Права на отдельные столбцы таблицы можно предоставить с помощью GRANT Select_priv(col1,col2) ON ctl.db.tbl TO user1.

В настоящее время для столбцов поддерживается только право Select_priv.

Права на уровне строк​

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

В частности, администраторы могут создавать правила, которые фильтруют строки или ограничивают доступ пользователей к ним на основе фактических значений, хранящихся в данных.

Начиная с версии 1.2, права на уровне строк можно создавать командой CREATE ROW POLICY.

Начиная с версии 2.1.2, поддерживается настройка прав на уровне строк через механизм Row Level Filter в Apache Ranger.

Права на использование​

  • Права на Resource

    Права на ресурсы задаются специально для Resources, не связаны с правами на базы данных или таблицы и позволяют назначать только Usage_priv и Grant_priv.

    Права на все Resources можно предоставить с помощью GRANT USAGE_PRIV ON RESOURCE '%' TO user1.

  • Права на Workload Group

    Права на Workload Group задаются специально для Workload Groups, не связаны с правами на базы данных или таблицы и позволяют назначать только Usage_priv и Grant_priv.

    Права на все Workload Groups можно предоставить с помощью GRANT USAGE_PRIV ON WORKLOAD GROUP '%' TO user1.

Маскирование данных​

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

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

Начиная с версии 2.1.2, поддерживается настройка политик маскирования данных для отдельных столбцов через механизм Data Masking в Apache Ranger. В настоящее время такие политики можно настроить только через Apache Ranger.

Встроенная схема авторизации Doris​

Система прав доступа 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.

Для удобства права можно предоставлять непосредственно пользователю. Внутри системы для каждого пользователя создаётся уникальная роль по умолчанию. Предоставление прав пользователю фактически означает предоставление прав его роли по умолчанию.

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

Схема авторизации на основе Apache Ranger​

См. раздел Схема авторизации на основе Apache Ranger.

Частые вопросы​

Пояснения к правам доступа​

  1. Пользователи с правами ADMIN или правами GRANT на уровне GLOBAL могут выполнять следующие операции:

    • CREATE USER
    • DROP USER
    • ALTER USER
    • SHOW GRANTS
    • CREATE ROLE
    • DROP ROLE
    • ALTER ROLE
    • SHOW ROLES
    • SHOW PROPERTY FOR USER

  2. GRANT/REVOKE

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

  3. SET PASSWORD

    • Пользователи с правами ADMIN или правами GRANT на уровне GLOBAL могут задавать пароли пользователей, отличных от root.
    • Обычные пользователи могут задавать пароль для собственного идентификатора пользователя. Свой идентификатор пользователя можно посмотреть командой SELECT CURRENT_USER().
    • Пользователи ROOT могут изменять собственный пароль.

Дополнительные сведения​

  1. При инициализации Doris автоматически создаются следующие пользователи и роли:

    • Роль operator: обладает правами Node_priv и Admin_priv, то есть всеми правами в Doris.
    • Роль admin: обладает правом Admin_priv, то есть всеми правами, кроме изменения узлов.
    • root@'%': пользователь root, которому разрешён вход с любого узла и назначена роль operator.
    • admin@'%': пользователь admin, которому разрешён вход с любого узла и назначена роль admin.

  2. Удаление созданных по умолчанию пользователей и ролей, а также изменение их прав не поддерживается.

    • Удаление пользователей root@'%' и admin@'%' не поддерживается, но разрешено создавать и удалять пользователей root@'xxx' и admin@'xxx' (где xxx обозначает любой хост, кроме %). Doris рассматривает таких пользователей как обычных.
    • Отзыв ролей по умолчанию у root@'%' и admin@'%' не поддерживается.
    • Удаление ролей operator и admin не поддерживается.
    • Изменение прав ролей operator и admin не поддерживается.

  3. Роль operator назначена только одному пользователю — Root. Роль admin может быть назначена нескольким пользователям.

  4. Ниже приведены пояснения к некоторым операциям, которые могут приводить к конфликтам:

    1. Конфликт домена и IP-адреса:

      Предположим, создан следующий пользователь:

      CREATE USER user1@['domain'];

      Ему предоставлены права:

      GRANT SELECT_PRIV ON *.* TO user1@['domain']

      Это доменное имя преобразуется в два IP-адреса: ip1 и ip2.

      Предположим, позднее мы предоставляем отдельное право пользователю user1@'ip1':

      GRANT ALTER_PRIV ON *.* TO user1@'ip1';

      Тогда user1@'ip1' будет обладать правами Select_priv и Alter_priv. При последующем изменении прав user1@['domain'] права user1@'ip1' уже не будут изменяться вслед за ними.

    2. Конфликт пересекающихся IP-адресов:

      Предположим, созданы следующие пользователи:

      CREATE USER user1@'%' IDENTIFIED BY "12345";
      CREATE USER user1@'192.%' IDENTIFIED BY "abcde";

      Запись '192.%' имеет более высокий приоритет, чем '%', поэтому, если пользователь user1 с компьютера 192.168.1.1 попытается войти в Doris с паролем '12345', доступ будет отклонён.

  5. Забытый пароль

    Если вы забыли пароль и не можете войти в Doris, добавьте skip_localhost_auth_check=true в конфигурационный файл FE и перезапустите FE. После этого можно войти в Doris с локального компьютера от имени root без пароля.

    После входа можно сбросить пароль командой SET PASSWORD.

  6. Никто, кроме самого пользователя root, не может сбросить его пароль.

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

  8. current_user() и user()

    Пользователи могут просмотреть свои current_user и user, выполнив SELECT current_user() и SELECT user() соответственно. Здесь current_user обозначает идентификатор, с которым пользователь прошёл аутентификацию, а user — фактический идентификатор пользователя в данный момент.

    Например:

    Предположим, создан user1@'192.%', после чего пользователь user1 входит с адреса 192.168.10.1. В этом случае current_user будет равен user1@'192.%', а user — user1@'192.168.10.1'.

    Все права предоставляются определённому current_user, а фактический пользователь получает все права соответствующего current_user.

Рекомендации по использованию​

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

  1. Сценарий 1

    Пользователи кластера Doris делятся на администраторов (Admin), инженеров-разработчиков (RD) и пользователей (Client). Администраторы имеют все права во всём кластере и в основном отвечают за настройку кластера и управление узлами. Инженеры-разработчики отвечают за моделирование данных для бизнес-задач, включая создание баз данных и таблиц, загрузку и изменение данных. Пользователи обращаются к различным базам данных и таблицам для получения данных.

    В этом сценарии администраторам можно предоставить права ADMIN или GRANT. Разработчикам RD можно предоставить права CREATE, DROP, ALTER, LOAD и SELECT для любых или определённых баз данных и таблиц. Пользователям Client можно предоставить права SELECT для любых или определённых баз данных и таблиц. Кроме того, для упрощения предоставления прав нескольким пользователям можно создать разные роли.

  2. Сценарий 2

    В одном кластере могут размещаться данные нескольких бизнес-направлений, каждое из которых может использовать один или несколько наборов данных. Каждому направлению необходимо управлять своими пользователями. В этом сценарии администратор может создать для каждой базы данных пользователя с правами GRANT на уровне DATABASE. Такой пользователь сможет предоставлять права только на указанную базу данных.

  3. Чёрный список

    Doris поддерживает только белый список, но с помощью определённых приёмов можно имитировать чёрный список. Предположим, создан пользователь с именем user@'192.%', которому разрешён вход с адресов 192.*. Если необходимо запретить вход с адреса 192.168.10.1, можно создать другого пользователя cmy@'192.168.10.1' с новым паролем. Поскольку 192.168.10.1 имеет более высокий приоритет, чем 192.%, пользователь с адреса 192.168.10.1 больше не сможет войти со старым паролем.

Report issue