LDAP
Для аутентификации пользователей ClickHouse можно использовать сервер LDAP. Существуют два подхода:
- Использовать LDAP как внешний аутентификатор для существующих пользователей, которые определены в users.xml, или в локальных параметрах управления доступом.
- Использовать LDAP как внешний пользовательский каталог и разрешить аутентификацию локально неопределенных пользователей, если они есть на LDAP сервере.
Для обоих подходов необходимо определить внутреннее имя LDAP сервера в конфигурации ClickHouse, чтобы другие параметры конфигурации могли ссылаться на это имя.
Определение LDAP сервера
Чтобы определить LDAP сервер, необходимо добавить секцию ldap_servers в config.xml.
Пример
Обратите внимание, что можно определить несколько LDAP серверов внутри секции ldap_servers, используя различные имена.
Параметры
- host— имя хоста сервера LDAP или его IP. Этот параметр обязательный и не может быть пустым.
- port— порт сервера LDAP. Если настройка- enable_tlsравна- true, то по умолчанию используется порт- 636, иначе — порт- 389.
- bind_dn— шаблон для создания DN подключения.- При формировании DN все подстроки {user_name}в шаблоне будут заменяться на фактическое имя пользователя при каждой попытке аутентификации.
 
- При формировании DN все подстроки 
- user_dn_detection— секция с параметрами LDAP поиска для определения фактического значения DN подключенного пользователя.- Это в основном используется в фильтрах поиска для дальнейшего сопоставления ролей, когда сервер является Active Directory. Полученный DN пользователя будет использоваться при замене подстрок {user_dn}везде, где они разрешены. По умолчанию DN пользователя устанавливается равным DN подключения, но после выполнения поиска он будет обновлен до фактического найденного значения DN пользователя.- base_dn— шаблон для создания базового DN для LDAP поиска.- При формировании DN все подстроки {user_name}и{bind_dn}в шаблоне будут заменяться на фактическое имя пользователя и DN подключения соответственно при каждом LDAP поиске.
 
- При формировании DN все подстроки 
- scope— область LDAP поиска.- Возможные значения: base,one_level,children,subtree(по умолчанию).
 
- Возможные значения: 
- search_filter— шаблон для создания фильтра для каждого LDAP поиска.- При формировании фильтра все подстроки {user_name},{bind_dn},{user_dn}и{base_dn}в шаблоне будут заменяться на фактическое имя пользователя, DN подключения, DN пользователя и базовый DN соответственно при каждом LDAP поиске.
- Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
 
- При формировании фильтра все подстроки 
 
 
- Это в основном используется в фильтрах поиска для дальнейшего сопоставления ролей, когда сервер является Active Directory. Полученный DN пользователя будет использоваться при замене подстрок 
- verification_cooldown— промежуток времени (в секундах) после успешной попытки подключения, в течение которого пользователь будет считаться аутентифицированным и сможет выполнять запросы без повторного обращения к серверам LDAP.- Чтобы отключить кеширование и заставить обращаться к серверу LDAP для каждого запроса аутентификации, укажите 0(значение по умолчанию).
 
- Чтобы отключить кеширование и заставить обращаться к серверу LDAP для каждого запроса аутентификации, укажите 
- enable_tls— флаг, включающий использование защищенного соединения с сервером LDAP.- Укажите noдля использования текстового протоколаldap://(не рекомендовано).
- Укажите yesдля обращения к LDAP по протоколу SSL/TLSldaps://(рекомендовано, используется по умолчанию).
- Укажите 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— путь к файлу ЦС (certification authority) сертификата.
- tls_ca_cert_dir— путь к каталогу, содержащему сертификаты ЦС.
- tls_cipher_suite— разрешенный набор шифров (в нотации OpenSSL).
Внешний аутентификатор LDAP
Удаленный сервер LDAP можно использовать для верификации паролей локально определенных пользователей (пользователей, которые определены в users.xml или в локальных параметрах управления доступом). Для этого укажите имя определенного ранее сервера LDAP вместо password или другой аналогичной секции в настройках пользователя.
При каждой попытке авторизации ClickHouse пытается "привязаться" к DN, указанному в определении LDAP сервера, используя параметр bind_dn и предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается аутентифицированным. Обычно это называют методом "простой привязки".
Пример
Обратите внимание, что пользователь my_user ссылается на my_ldap_server. Этот LDAP сервер должен быть настроен в основном файле config.xml, как это было описано ранее.
При включенном SQL-ориентированном управлении доступом пользователи, аутентифицированные LDAP серверами, могут также быть созданы запросом CREATE USER.
Запрос:
Внешний пользовательский каталог LDAP
В дополнение к локально определенным пользователям, удаленный LDAP сервер может служить источником определения пользователей. Для этого укажите имя определенного ранее сервера LDAP (см. Определение LDAP сервера) в секции ldap внутри секции users_directories файла config.xml.
При каждой попытке аутентификации ClickHouse пытается локально найти определение пользователя и аутентифицировать его как обычно. Если пользователь не находится локально, ClickHouse предполагает, что он определяется во внешнем LDAP каталоге и пытается "привязаться" к DN, указанному на LDAP сервере, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается существующим и  аутентифицированным. Пользователю присваиваются роли из списка, указанного в секции roles. Кроме того, если настроена секция role_mapping, то выполняется LDAP поиск, а его результаты преобразуются в имена ролей и присваиваются пользователям. Все это работает при условии, что SQL-ориентированное управлением доступом включено, а роли созданы запросом CREATE ROLE.
Пример
В config.xml.
Обратите внимание, что 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}и{user_dn}в шаблоне будут заменяться на фактическое имя пользователя, DN подключения и DN пользователя соответственно при каждом LDAP поиске.
 
- При формировании DN все подстроки 
- scope— область LDAP поиска.- Возможные значения: base,one_level,children,subtree(по умолчанию).
 
- Возможные значения: 
- search_filter— шаблон для создания фильтра для каждого LDAP поиска.- При формировании фильтра все подстроки {user_name},{bind_dn},{user_dn}и{base_dn}в шаблоне будут заменяться на фактическое имя пользователя, DN подключения, DN пользователя и базовый DN соответственно при каждом LDAP поиске.
- Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
 
- При формировании фильтра все подстроки 
- attribute— имя атрибута, значение которого будет возвращаться LDAP поиском. По умолчанию:- cn.
- prefix— префикс, который, как предполагается, будет находиться перед началом каждой строки в исходном списке строк, возвращаемых LDAP поиском. Префикс будет удален из исходных строк, а сами они будут рассматриваться как имена локальных ролей. По умолчанию: пустая строка.
 
 
- При аутентификации пользователя, пока еще связанного с LDAP, производится LDAP поиск с помощью