ClickHouse/docs/ru/operations/external-authenticators/ldap.md

LDAP

Для аутентификации пользователей ClickHouse можно использовать сервер LDAP. Существуют два подхода:

• Использовать LDAP как внешний аутентификатор для существующих пользователей, которые определены в users.xml или в локальных параметрах управления доступом.
• Использовать LDAP как внешний пользовательский каталог и разрешить аутентификацию локально неопределенных пользователей, если они есть на LDAP сервере.

Для обоих подходов необходимо определить внутреннее имя LDAP сервера в конфигурации ClickHouse, чтобы другие параметры конфигурации могли ссылаться на это имя.

Определение LDAP сервера

Чтобы определить LDAP сервер, необходимо добавить секцию ldap_servers в config.xml.

Пример

<yandex>
    <!- ... -->
    <ldap_servers>
        <my_ldap_server>
            <host>localhost</host>
            <port>636</port>
            <bind_dn>uid={user_name},ou=users,dc=example,dc=com</bind_dn>
            <verification_cooldown>300</verification_cooldown>
            <enable_tls>yes</enable_tls>
            <tls_minimum_protocol_version>tls1.2</tls_minimum_protocol_version>
            <tls_require_cert>demand</tls_require_cert>
            <tls_cert_file>/path/to/tls_cert_file</tls_cert_file>
            <tls_key_file>/path/to/tls_key_file</tls_key_file>
            <tls_ca_cert_file>/path/to/tls_ca_cert_file</tls_ca_cert_file>
            <tls_ca_cert_dir>/path/to/tls_ca_cert_dir</tls_ca_cert_dir>
            <tls_cipher_suite>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384</tls_cipher_suite>
        </my_ldap_server>
    </ldap_servers>
</yandex>

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

Параметры

• host — имя хоста сервера LDAP или его IP. Этот параметр обязательный и не может быть пустым.
• port — порт сервера LDAP. Если настройка enable_tls равна true, то по умолчанию используется порт 636, иначе — порт 389.
• bind_dn — шаблон для создания DN для привязки.
  • При формировании DN все подстроки {user_name} в шаблоне будут заменяться на фактическое имя пользователя при каждой попытке аутентификации.
• verification_cooldown — промежуток времени (в секундах) после успешной попытки привязки, в течение которого пользователь будет считаться аутентифицированным и сможет выполнять запросы без повторного обращения к серверам LDAP.
  • Укажите 0 (по-умолчанию), чтобы отключить кеширование и заставить связываться с сервером LDAP для каждого запроса аутентификации.
• enable_tls — флаг, включающий использование защищенного соединения с сервером LDAP.
  • Укажите no для текстового ldap:// протокола (не рекомендовано).
  • Укажите yes для LDAP через SSL/TLS ldaps:// протокола (рекомендовано, используется по-умолчанию).
  • Укажите starttls для устаревшего StartTLS протокола (текстовый ldap:// протокол, модернизированный до TLS).
• tls_minimum_protocol_version — минимальная версия протокола SSL/TLS.
  • Принимаемые значения: ssl2, ssl3, tls1.0, tls1.1, tls1.2 (по-умолчанию).
• tls_require_cert — поведение при проверке сертификата SSL/TLS.
  • Принимаемые значения: never, allow, try, demand (по-умолчанию).
• tls_cert_file — путь к файлу сертификата.
• tls_key_file — путь к файлу ключа сертификата.
• tls_ca_cert_file — путь к файлу ЦС сертификата.
• tls_ca_cert_dir — путь к каталогу, содержащая сертификаты ЦС.
• tls_cipher_suite — разрешенный набор шифров (в нотации OpenSSL).

Внешний аутентификатор LDAP

Удаленный сервер LDAP можно использовать как метод верификации паролей локально определенных пользователей (пользователей, которые определены в users.xml или в локальных путях управления контролем). Для этого укажите имя определенного до этого сервера LDAP вместо password или другой похожей секции в определении пользователя.

При каждой попытке авторизации, ClickHouse пытается "привязаться" к DN, указанному в определении LDAP сервера параметром bind_dn, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается аутентифицированным. Обычно это называют методом "простой привязки".

Пример

<yandex>
    <!- ... -->
    <users>
        <!- ... -->
        <my_user>
            <!- ... -->
            <ldap>
                <server>my_ldap_server</server>
            </ldap>
        </my_user>
    </users>
</yandex>

Обратите внимание, что пользователь my_user ссылается на my_ldap_server. Этот LDAP сервер должен быть настроен в основном файле config.xml, как это было описано ранее.

При включенном SQL-ориентированным Управлением доступом пользователи, аутентифицированные LDAP серверами, могут также быть созданы выражением CREATE USER.

Запрос:

CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';

Внешний пользовательский каталог LDAP

В добавок к локально определенным пользователям, удаленный LDAP сервер может быть использован как источник определения пользователей. Для этого укажите имя определенного до этого сервера LDAP (см. Определение LDAP сервера) в секции ldap внутри секции users_directories файла config.xml.

При каждой попытке авторизации ClicHouse пытается локально найти определение пользователя и авторизовать его как обычно. Если определение не будет найдено, ClickHouse предполагает, что оно находится во внешнем LDAP каталоге, и пытается "привязаться" к DN, указанному на LDAP сервере, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается существующим и аутентифицированным. Пользователю будут присвоены роли из списка, указанного в секции roles. Кроме того, может быть выполнен LDAP поиск, а его результаты могут быть преобразованы в имена ролей и присвоены пользователям, если была настроена секция role_mapping. Все это работает при условии, что SQL-ориентированное Управлением доступом включено, а роли созданы выражением CREATE ROLE.

Пример

В config.xml.

<yandex>
    <!- ... -->
    <user_directories>
        <!- ... -->
        <ldap>
            <server>my_ldap_server</server>
            <roles>
                <my_local_role1 />
                <my_local_role2 />
            </roles>
            <role_mapping>
                <base_dn>ou=groups,dc=example,dc=com</base_dn>
                <scope>subtree</scope>
                <search_filter>(&amp;(objectClass=groupOfNames)(member={bind_dn}))</search_filter>
                <attribute>cn</attribute>
                <prefix>clickhouse_</prefix>
            </role_mapping>
        </ldap>
    </user_directories>
</yandex>

Обратите внимание, что my_ldap_server, указанный в секции ldap внутри секции user_directories, должен быть настроен в файле config.xml, как это было описано ранее. (см. Определение LDAP сервера).

Параметры

• server — одно из имен сервера LDAP, определенного в секции конфига ldap_servers выше. Этот параметр обязательный и не может быть оставлен пустым.
• roles — секция со списком локально определенных ролей, которые будут присвоены каждому пользователю, полученному от сервера LDAP.
  • Если роли не указаны здесь или в секции role_mapping (ниже), пользователь не сможет выполнять никаких операций после аутентификации.
• role_mapping — секция c параметрами LDAP поиска и правилами отображения.
  • При аутентификации пользователя, пока еще связанного с LDAP, производится LDAP поиск с помощью search_filter и имени этого пользователя. Для каждой записи, найденной в ходе поиска, выделяется значение указанного атрибута. У каждого атрибута, имеющего указанный префикс, удаляется этот префикс, а остальная часть значения становится именем локальной роли, определенной в ClickHouse, причем предполагается, что эта роль была создана выражением CREATE ROLE до этого.
  • Внутри одной секции ldap может быть несколько секций role_mapping. Все они будут применены.
    • base_dn — шаблон, который используется для создания базового DN для LDAP поиска.
      • конечный DN будет создан заменой всех подстрок {user_name} и {bind_dn} шаблона на фактическое имя пользователя и DN привязки соответственно при каждом LDAP поиске.
    • scope — Область LDAP поиска.
      • Принимаемые значения: base, one_level, children, subtree (по-умолчанию).
    • search_filter — шаблон, который используется для создания фильтра для каждого LDAP поиска.
      • Конечный фильтр будет создан заменой всех подстрок {user_name}, {bind_dn} и {base_dn} шаблона на фактическое имя пользователя, DN привязи и базовый DN при соответственно каждом LDAP поиске.
      • Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
    • attribute — имя атрибута, значение которого будет возвращаться LDAP поиском.
    • prefix — префикс, который, как предполагается, будет находиться перед началом каждой строки в исходном списке строк, возвращаемых LDAP поиском. Префикс будет удален из исходных строк, а сами они будут рассматриваться как имена локальных ролей. По-умолчанию пусто.

Оригинальная статья