Перейти к основному содержанию
Перейти к основному содержанию

Настройка аутентификации по пользовательскому SSL‑сертификату

Not supported in ClickHouse Cloud
Примечание

This page is not applicable to ClickHouse Cloud. The feature documented here is not available in ClickHouse Cloud services. See the ClickHouse Cloud Compatibility guide for more information.

В этом руководстве приведены простые и минимально необходимые настройки для аутентификации с помощью пользовательских SSL-сертификатов. Настоящее руководство основано на разделе Configuring SSL-TLS user guide.

Примечание

Аутентификация пользователей по SSL поддерживается при использовании интерфейсов https, native, mysql и postgresql.

Для безопасной аутентификации на узлах ClickHouse необходимо установить <verificationMode>strict</verificationMode> (хотя значение relaxed подойдет для целей тестирования).

Если вы используете AWS NLB с интерфейсом MySQL, вам необходимо обратиться в службу поддержки AWS с просьбой включить недокументированную опцию:

I would like to be able to configure our NLB proxy protocol v2 as below proxy_protocol_v2.client_to_server.header_placement,Value=on_first_ack. :::

1. Создание пользовательских сертификатов SSL​

Примечание

В этом примере используются самоподписанные сертификаты с самоподписанным центром сертификации (CA). Для продуктивных сред создайте CSR и отправьте его вашей PKI‑команде или поставщику сертификатов, чтобы получить корректный сертификат.

  1. Сгенерируйте запрос на подпись сертификата (CSR) и ключ. Базовый формат следующий:

    openssl req -newkey rsa:2048 -nodes -subj "/CN=<my_host>:<my_user>"  -keyout <my_cert_name>.key -out <my_cert_name>.csr

    В этом примере мы используем следующие значения для домена и пользователя в тестовом окружении:

    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode1.marsnet.local:cert_user"  -keyout chnode1_cert_user.key -out chnode1_cert_user.csr
    Примечание

    Значение CN произвольно, и любая строка может быть использована в качестве идентификатора сертификата. Оно используется при создании пользователя на дальнейших шагах.

  2. Сгенерируйте и подпишите новый пользовательский сертификат, который будет использоваться для аутентификации. Базовый формат следующий:

    openssl x509 -req -in <my_cert_name>.csr -out <my_cert_name>.crt -CA <my_ca_cert>.crt -CAkey <my_ca_cert>.key -days 365

    В этом примере мы используем следующие значения для домена и пользователя в тестовом окружении:

    openssl x509 -req -in chnode1_cert_user.csr -out chnode1_cert_user.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365

2. Создание SQL‑пользователя и выдача прав​

Примечание

Подробные сведения о включении SQL‑пользователей и настройке ролей см. в руководстве пользователя Определение SQL‑пользователей и ролей.

  1. Создайте SQL‑пользователя, использующего аутентификацию по сертификату:

    CREATE USER cert_user IDENTIFIED WITH ssl_certificate CN 'chnode1.marsnet.local:cert_user';

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

    GRANT ALL ON *.* TO cert_user WITH GRANT OPTION;
    Примечание

    В этом упражнении пользователю для демонстрации предоставляются полные административные привилегии. Параметры прав доступа см. в документации по RBAC ClickHouse.

    Примечание

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

    <users>
    <cert_user>
        <ssl_certificates>
            <common_name>chnode1.marsnet.local:cert_user</common_name>
        </ssl_certificates>
        <networks>
            <ip>::/0</ip>
        </networks>
        <profile>default</profile>
        <access_management>1</access_management>
        <!-- дополнительные параметры-->
    </cert_user>
</users>

3. Тестирование​

  1. Скопируйте пользовательский сертификат, пользовательский ключ и сертификат CA (центра сертификации) на удалённый узел.

  2. Настройте OpenSSL в конфигурации клиента ClickHouse, указав сертификат и пути к файлам.

    <openSSL>
    <client>
        <certificateFile>my_cert_name.crt</certificateFile>
        <privateKeyFile>my_cert_name.key</privateKeyFile>
        <caConfig>my_ca_cert.crt</caConfig>
    </client>
</openSSL>

  3. Запустите clickhouse-client.

    clickhouse-client --user <my_user> --query 'SHOW TABLES'
    Примечание

    Обратите внимание, что пароль, переданный в clickhouse-client, игнорируется, если в конфигурации указан сертификат.

4. Тестирование HTTP​

  1. Скопируйте пользовательский сертификат, пользовательский ключ и сертификат УЦ на удалённый узел.

  2. Используйте curl, чтобы проверить выполнение примерной SQL-команды. Базовый формат команды:

    echo 'SHOW TABLES' | curl 'https://<clickhouse_node>:8443' --cert <my_cert_name>.crt --key <my_cert_name>.key --cacert <my_ca_cert>.crt -H "X-ClickHouse-SSL-Certificate-Auth: on" -H "X-ClickHouse-User: <my_user>" --data-binary @-

    Например:

    echo 'SHOW TABLES' | curl 'https://chnode1:8443' --cert chnode1_cert_user.crt --key chnode1_cert_user.key --cacert marsnet_ca.crt -H "X-ClickHouse-SSL-Certificate-Auth: on" -H "X-ClickHouse-User: cert_user" --data-binary @-

    Вывод будет похож на следующий:

    INFORMATION_SCHEMA
default
information_schema
system
    Примечание

    Обратите внимание, что пароль не указывался: сертификат используется вместо пароля, и именно с его помощью ClickHouse аутентифицирует пользователя.

Итоги​

В этой статье мы рассмотрели основы создания и настройки пользователя для аутентификации с использованием SSL-сертификата. Этот метод может применяться с clickhouse-client или любыми клиентами, которые поддерживают интерфейс https и позволяют задавать HTTP-заголовки. Сгенерированные сертификат и ключ должны храниться в конфиденциальности и с ограниченным доступом, поскольку сертификат используется для аутентификации и авторизации пользователя при выполнении операций в базе данных ClickHouse. Относитесь к сертификату и ключу так же, как к паролям.