Skip to content
ClickHouse Docs
ClickHouse DocsClickHouse Docs

Configurer TLS

Non pris en charge par ClickHouse Cloud

Ce guide présente des paramètres simples et minimaux pour configurer ClickHouse afin d’utiliser des certificats OpenSSL pour valider les connexions. Pour cette démonstration, un certificat d’autorité de certification (CA) auto-signé et sa clé, ainsi que des certificats de nœud, sont créés afin d’établir les connexions avec les paramètres appropriés.

Créer un déploiement ClickHouse

Ce guide a été rédigé avec Ubuntu 20.04, et ClickHouse a été installé sur les hôtes suivants à l’aide du paquet DEB (avec apt). Le domaine est marsnet.local :

Hôte Adresse IP
chnode1 192.168.1.221
chnode2 192.168.1.222
chnode3 192.168.1.223

Créer des certificats TLS

  1. Générez une clé qui sera utilisée pour la nouvelle CA :

    openssl genrsa -out marsnet_ca.key 2048
  2. Générez un nouveau certificat de CA auto-signé. La commande suivante créera un nouveau certificat qui sera utilisé pour signer d’autres certificats à l’aide de la clé de la CA :

    openssl req -x509 -subj "/CN=marsnet.local CA" -nodes -key marsnet_ca.key -days 1095 -out marsnet_ca.crt
  1. Vérifiez le contenu du nouveau certificat de CA :

    openssl x509 -in marsnet_ca.crt -text
  2. Créez une demande de certificat (CSR) et générez une clé pour chaque nœud :

    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode1" -addext "subjectAltName = DNS:chnode1.marsnet.local,IP:192.168.1.221" -keyout chnode1.key -out chnode1.csr
    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode2" -addext "subjectAltName = DNS:chnode2.marsnet.local,IP:192.168.1.222" -keyout chnode2.key -out chnode2.csr
    openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode3" -addext "subjectAltName = DNS:chnode3.marsnet.local,IP:192.168.1.223" -keyout chnode3.key -out chnode3.csr
  3. À l’aide des CSR et de la CA, créez de nouvelles paires certificat-clé :

    openssl x509 -req -in chnode1.csr -out chnode1.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
    openssl x509 -req -in chnode2.csr -out chnode2.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
    openssl x509 -req -in chnode3.csr -out chnode3.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365 -copy_extensions copy
  4. Vérifiez le sujet et l’émetteur des certificats :

    openssl x509 -in chnode1.crt -text -noout
  5. Vérifiez que les nouveaux certificats sont bien validés par le certificat de CA :

    openssl verify -CAfile marsnet_ca.crt chnode1.crt
    chnode1.crt: OK

Créez et configurez un répertoire pour stocker les certificats et les clés.

  1. Créez, sur chaque nœud, un dossier dans un répertoire accessible à ClickHouse. Nous recommandons le répertoire de configuration par défaut (par exemple /etc/clickhouse-server) :

    mkdir /etc/clickhouse-server/certs
  2. Copiez le certificat de l’autorité de certification (CA), le certificat du nœud et la clé correspondant à chaque nœud dans le nouveau répertoire certs.

  3. Modifiez le propriétaire et les permissions afin de permettre à ClickHouse de lire les certificats :

    chown clickhouse:clickhouse -R /etc/clickhouse-server/certs
    chmod 600 /etc/clickhouse-server/certs/*
    chmod 755 /etc/clickhouse-server/certs
    ll /etc/clickhouse-server/certs
    total 20
    drw-r--r-- 2 clickhouse clickhouse 4096 Apr 12 20:23 ./
    drwx------ 5 clickhouse clickhouse 4096 Apr 12 20:23 ../
    -rw------- 1 clickhouse clickhouse  997 Apr 12 20:22 chnode1.crt
    -rw------- 1 clickhouse clickhouse 1708 Apr 12 20:22 chnode1.key
    -rw------- 1 clickhouse clickhouse 1131 Apr 12 20:23 marsnet_ca.crt

Configurer l’environnement avec des clusters de base à l’aide de ClickHouse Keeper

Pour cet environnement de déploiement, les paramètres ClickHouse Keeper suivants sont utilisés sur chaque nœud. Chaque serveur possède son propre <server_id>. (Par exemple, <server_id>1</server_id> pour le nœud chnode1, et ainsi de suite.)

  1. Ajoutez le contenu suivant dans la balise <clickhouse> du config.xml du serveur ClickHouse
<keeper_server>
    <tcp_port_secure>9281</tcp_port_secure>
    <server_id>1</server_id>
    <log_storage_path>/var/lib/clickhouse/coordination/log</log_storage_path>
    <snapshot_storage_path>/var/lib/clickhouse/coordination/snapshots</snapshot_storage_path>

    <coordination_settings>
        <operation_timeout_ms>10000</operation_timeout_ms>
        <session_timeout_ms>30000</session_timeout_ms>
        <raft_logs_level>trace</raft_logs_level>
    </coordination_settings>

    <raft_configuration>
        <secure>true</secure>
        <server>
            <id>1</id>
            <hostname>chnode1.marsnet.local</hostname>
            <port>9444</port>
        </server>
        <server>
            <id>2</id>
            <hostname>chnode2.marsnet.local</hostname>
            <port>9444</port>
        </server>
        <server>
            <id>3</id>
            <hostname>chnode3.marsnet.local</hostname>
            <port>9444</port>
        </server>
    </raft_configuration>
</keeper_server>
  1. Décommentez et mettez à jour les paramètres de Keeper sur tous les nœuds, puis définissez l’option <secure> sur 1 :

    <zookeeper>
        <node>
            <host>chnode1.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
        <node>
            <host>chnode2.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
        <node>
            <host>chnode3.marsnet.local</host>
            <port>9281</port>
            <secure>1</secure>
        </node>
    </zookeeper>
  2. Mettez à jour et ajoutez les paramètres de cluster suivants sur chnode1 et chnode2. chnode3 sera utilisé pour constituer le quorum de ClickHouse Keeper.

La configuration suivante crée un cluster avec un réplica de segment sur deux serveurs (un par nœud).

<remote_servers>
    <cluster_1S_2R>
        <shard>
            <replica>
                <host>chnode1.marsnet.local</host>
                <port>9440</port>
                <user>default</user>
                <password>ClickHouse123!</password>
                <secure>1</secure>
            </replica>
            <replica>
                <host>chnode2.marsnet.local</host>
                <port>9440</port>
                <user>default</user>
                <password>ClickHouse123!</password>
                <secure>1</secure>
            </replica>
        </shard>
    </cluster_1S_2R>
</remote_servers>
  1. Définissez les valeurs de macros afin de pouvoir créer une table ReplicatedMergeTree pour les tests. Sur chnode1 :

    <macros>
        <shard>1</shard>
        <replica>replica_1</replica>
    </macros>

    Sur chnode2 :

    <macros>
        <shard>1</shard>
        <replica>replica_2</replica>
    </macros>

Configurer les interfaces TLS sur les nœuds ClickHouse

Les paramètres ci-dessous sont configurés dans le config.xml du serveur ClickHouse

  1. Définissez le nom d’affichage du déploiement (facultatif) :

    <display_name>clickhouse</display_name>
  2. Configurez ClickHouse pour écouter sur les ports externes :

    <listen_host>0.0.0.0</listen_host>
  3. Configurez le port https et désactivez le port http sur chaque nœud :

    <https_port>8443</https_port>
    {/*<http_port>8123</http_port>*/}
  4. Configurez le port TCP sécurisé natif de ClickHouse et désactivez le port non sécurisé par défaut sur chaque nœud :

    <tcp_port_secure>9440</tcp_port_secure>
    {/*<tcp_port>9000</tcp_port>*/}
  5. Configurez le port interserver https et désactivez le port non sécurisé par défaut sur chaque nœud :

    <interserver_https_port>9010</interserver_https_port>
    {/*<interserver_http_port>9009</interserver_http_port>*/}
  6. Configurez OpenSSL avec les certificats et les chemins d’accès

<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-server/certs/chnode1.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/certs/chnode1.key</privateKeyFile>
        <verificationMode>relaxed</verificationMode>
        <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>relaxed</verificationMode>
        <invalidCertificateHandler>
            <name>RejectCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

Pour plus d’informations, consultez cette page

  1. Configurez TLS pour gRPC sur chaque nœud :

    <grpc>
        <enable_ssl>1</enable_ssl>
        <ssl_cert_file>/etc/clickhouse-server/certs/chnode1.crt</ssl_cert_file>
        <ssl_key_file>/etc/clickhouse-server/certs/chnode1.key</ssl_key_file>
        <ssl_require_client_auth>true</ssl_require_client_auth>
        <ssl_ca_cert_file>/etc/clickhouse-server/certs/marsnet_ca.crt</ssl_ca_cert_file>
        <transport_compression_type>none</transport_compression_type>
        <transport_compression_level>0</transport_compression_level>
        <max_send_message_size>-1</max_send_message_size>
        <max_receive_message_size>-1</max_receive_message_size>
        <verbose_logs>false</verbose_logs>
    </grpc>

    Pour plus d’informations, consultez https://clickhouse.com/docs/interfaces/grpc/

  2. Configurez le client ClickHouse sur au moins un des nœuds afin d’utiliser TLS pour ses connexions, dans son propre fichier config.xml (situé par défaut dans /etc/clickhouse-client/) :

    <openSSL>
        <client>
            <loadDefaultCAFile>false</loadDefaultCAFile>
            <caConfig>/etc/clickhouse-server/certs/marsnet_ca.crt</caConfig>
            <cacheSessions>true</cacheSessions>
            <disableProtocols>sslv2,sslv3</disableProtocols>
            <preferServerCiphers>true</preferServerCiphers>
            <invalidCertificateHandler>
                <name>RejectCertificateHandler</name>
            </invalidCertificateHandler>
        </client>
    </openSSL>
  3. Désactivez les ports d’émulation par défaut pour MySQL et PostgreSQL :

    {/*mysql_port>9004</mysql_port*/}
    {/*postgresql_port>9005</postgresql_port*/}

Test

  1. Démarrez tous les nœuds, un à la fois :

    service clickhouse-server start
  2. Vérifiez que les ports sécurisés sont actifs et en écoute ; le résultat devrait ressembler à cet exemple sur chaque nœud :

    root@chnode1:/etc/clickhouse-server# netstat -ano | grep tcp
    tcp        0      0 0.0.0.0:9010            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:8443            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:9440            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 0.0.0.0:9281            0.0.0.0:*               LISTEN      off (0.00/0/0)
    tcp        0      0 192.168.1.221:33046     192.168.1.222:9444      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:42730     192.168.1.223:9444      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:51952     192.168.1.222:9281      ESTABLISHED off (0.00/0/0)
    tcp        0      0 192.168.1.221:22        192.168.1.210:49801     ESTABLISHED keepalive (6618.05/0/0)
    tcp        0     64 192.168.1.221:22        192.168.1.210:59195     ESTABLISHED on (0.24/0/0)
    tcp6       0      0 :::22                   :::*                    LISTEN      off (0.00/0/0)
    tcp6       0      0 :::9444                 :::*                    LISTEN      off (0.00/0/0)
    tcp6       0      0 192.168.1.221:9444      192.168.1.222:59046     ESTABLISHED off (0.00/0/0)
    tcp6       0      0 192.168.1.221:9444      192.168.1.223:41976     ESTABLISHED off (0.00/0/0)
    Port de ClickHouse Description
    8443 interface HTTPS
    9010 port HTTPS interserveur
    9281 port sécurisé de ClickHouse Keeper
    9440 protocole TCP natif sécurisé
    9444 port Raft de ClickHouse Keeper
  3. Vérifier l’état de santé de ClickHouse Keeper Les commandes mot de 4 lettres (4lW) habituelles ne fonctionnent pas avec echo sans TLS ; voici comment les utiliser avec openssl.

    • Ouvrez une session interactive avec openssl
openssl s_client -connect chnode1.marsnet.local:9281
CONNECTED(00000003)
depth=0 CN = chnode1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = chnode1
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:CN = chnode1
   i:CN = marsnet.local CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICtDCCAZwCFD321grxU3G5pf6hjitf2u7vkusYMA0GCSqGSIb3DQEBCwUAMBsx
...
  • Saisissez les commandes 4LW dans la session OpenSSL

    mntr
    ---
    Post-Handshake New Session Ticket arrived:
    SSL-Session:
        Protocol  : TLSv1.3
    ...
    read R BLOCK
    zk_version      v22.7.3.5-stable-e140b8b5f3a5b660b6b576747063fd040f583cf3
    zk_avg_latency  0
    zk_max_latency  4087
    zk_min_latency  0
    zk_packets_received     4565774
    zk_packets_sent 4565773
    zk_num_alive_connections        2
    zk_outstanding_requests 0
    zk_server_state leader
    zk_znode_count  1087
    zk_watch_count  26
    zk_ephemerals_count     12
    zk_approximate_data_size        426062
    zk_key_arena_size       258048
    zk_latest_snapshot_size 0
    zk_open_file_descriptor_count   187
    zk_max_file_descriptor_count    18446744073709551615
    zk_followers    2
    zk_synced_followers     1
    closed
  1. Démarrez le client ClickHouse avec l’option --secure et le port TLS :

    root@chnode1:/etc/clickhouse-server# clickhouse-client --user default --password ClickHouse123! --port 9440 --secure --host chnode1.marsnet.local
    ClickHouse client version 22.3.3.44 (official build).
    Connecting to chnode1.marsnet.local:9440 as user default.
    Connected to ClickHouse server version 22.3.3 revision 54455.
    
    clickhouse :)
  2. Connectez-vous à l’interface Play via l’interface https à l’adresse https://chnode1.marsnet.local:8443/play.

    Configurer TLS
  1. Créez une table répliquée :

    clickhouse :) CREATE TABLE repl_table ON CLUSTER cluster_1S_2R
                (
                    id UInt64,
                    column1 Date,
                    column2 String
                )
                ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/default/repl_table', '{replica}' )
                ORDER BY (id);
    ┌─host──────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐
    │ chnode2.marsnet.local │ 9440 │      0 │       │                   1 │                0 │
    │ chnode1.marsnet.local │ 9440 │      0 │       │                   0 │                0 │
    └───────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘
  2. Ajoutez quelques lignes sur chnode1 :

    INSERT INTO repl_table
    (id, column1, column2)
    VALUES
    (1,'2022-04-01','abc'),
    (2,'2022-04-02','def');
  3. Vérifiez la réplication en consultant les lignes sur chnode2 :

    SELECT * FROM repl_table
    ┌─id─┬────column1─┬─column2─┐
    │  1 │ 2022-04-01 │ abc     │
    │  2 │ 2022-04-02 │ def     │
    └────┴────────────┴─────────┘

Configurer OpenSSL pour un ClickHouse Keeper autonome

Lorsque ClickHouse Keeper s’exécute en tant que processus autonome (au lieu d’être intégré à ClickHouse server), les certificats et paramètres OpenSSL doivent être configurés séparément dans le fichier de configuration de Keeper. Sans cela, Keeper ne pourra pas établir de connexions sécurisées pour les communications client (tcp_port_secure) ni pour la réplication Raft entre les nœuds Keeper.

Ajoutez la section <openSSL> suivante au fichier de configuration du ClickHouse Keeper autonome sur chaque nœud :

<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-keeper/certs/chnode1.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-keeper/certs/chnode1.key</privateKeyFile>
        <verificationMode>relaxed</verificationMode>
        <caConfig>/etc/clickhouse-keeper/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <caConfig>/etc/clickhouse-keeper/certs/marsnet_ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>relaxed</verificationMode>
        <invalidCertificateHandler>
            <name>RejectCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

La section <server> est utilisée pour les connexions clientes entrantes sur le port Keeper sécurisé (tcp_port_secure). La section <client> est utilisée pour les connexions sortantes entre les nœuds Keeper lors de la réplication Raft.

Modes de vérification d’OpenSSL et gestionnaires de certificats

La configuration <openSSL> prend en charge plusieurs options pour <verificationMode> et <invalidCertificateHandler>, qui déterminent la manière dont ClickHouse valide les certificats TLS. Ces paramètres s’appliquent à clickhouse-server, clickhouse-client et à ClickHouse Keeper autonome.

Modes de vérification

Définissez <verificationMode> dans la section <server> ou <client> de <openSSL> :

Mode Description
none Aucune vérification du certificat. La connexion est chiffrée, mais l’identité du pair n’est pas vérifiée. À utiliser uniquement pour les tests.
relaxed Vérifie le certificat du pair s’il est présenté, mais n’échoue pas si aucun certificat n’est fourni.
once Côté serveur, vérifie le certificat client uniquement lors du handshake initial et sans renégociation. Côté client, se comporte comme relaxed.
strict Exige le certificat du pair et le vérifie intégralement. La connexion échoue si le certificat est absent, expiré ou non signé par une CA de confiance. Recommandé pour la production.

Gestionnaires de certificats invalides

Définissez <invalidCertificateHandler> dans la section <server> ou <client> de <openSSL>. Ce gestionnaire détermine le comportement à adopter lorsque la vérification du certificat échoue. Côté serveur, il contrôle la réponse aux certificats client invalides. Côté client, il contrôle la réponse aux certificats serveur invalides.

Gestionnaire Description
RejectCertificateHandler Rejette la connexion si le certificat est invalide. Il s'agit du paramètre par défaut, et de l'option recommandée.
AcceptCertificateHandler Accepte la connexion même si le certificat est invalide. À utiliser uniquement pour les tests.

Exemple : désactiver la vérification des certificats

Pour ignorer complètement la vérification des certificats (par exemple, lors de l’utilisation de certificats autosignés dans un environnement de test), définissez verificationMode sur none et utilisez AcceptCertificateHandler.

Pour clickhouse-client, vous pouvez également utiliser l’option de CLI --accept-invalid-certificate, qui applique automatiquement les deux paramètres.

clickhouse-client (/etc/clickhouse-client/config.xml) :

<openSSL>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

clickhouse-server (config.xml ou un fichier dans config.d/). La section <server> requiert toujours les chemins du certificat et de la clé, car le serveur doit présenter son propre certificat aux clients, même lorsqu’il ne vérifie pas les leurs :

<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-server/certs/server.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/certs/server.key</privateKeyFile>
        <verificationMode>none</verificationMode>
        <caConfig>/etc/clickhouse-server/certs/ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

ClickHouse Keeper autonome (fichier de configuration de Keeper) :

<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-keeper/certs/keeper.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-keeper/certs/keeper.key</privateKeyFile>
        <verificationMode>none</verificationMode>
        <caConfig>/etc/clickhouse-keeper/certs/ca.crt</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
    <client>
        <loadDefaultCAFile>false</loadDefaultCAFile>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
        <verificationMode>none</verificationMode>
        <invalidCertificateHandler>
            <name>AcceptCertificateHandler</name>
        </invalidCertificateHandler>
    </client>
</openSSL>

Résumé

Cet article a porté sur la configuration d’un environnement ClickHouse avec TLS. Les paramètres varient selon les exigences des environnements de production ; par exemple, les niveaux de vérification des certificats, les protocoles, les suites de chiffrement, etc. Vous devriez désormais avoir une bonne compréhension des étapes à suivre pour configurer et mettre en œuvre des connexions sécurisées.

Navigation