Configuration de l'authentification à l'aide d'un certificat utilisateur SSL

Ce guide présente les paramètres minimaux nécessaires pour configurer l’authentification à l’aide de certificats utilisateurs SSL.

Cette page ne s’applique pas à ClickHouse Cloud. La fonctionnalité décrite ici n’est pas disponible dans les services ClickHouse Cloud. Consultez le guide ClickHouse Compatibilité Cloud pour plus d’informations.

Ce guide présente des paramètres simples et minimaux pour configurer l’authentification à l’aide de certificats utilisateur SSL. Ce tutoriel s’appuie sur le guide de configuration de TLS.

L’authentification des utilisateurs par SSL est prise en charge avec les interfaces https, native, mysql et postgresql.

Les nœuds ClickHouse doivent avoir <verificationMode>strict</verificationMode> défini pour une authentification sécurisée (même si relaxed fonctionne à des fins de test).

Si vous utilisez AWS NLB avec l’interface MySQL, vous devez demander au support AWS d’activer l’option non documentée suivante :

Je souhaite pouvoir configurer le proxy protocol v2 de notre proxy NLB comme suit : proxy_protocol_v2.client_to_server.header_placement,Value=on_first_ack.

​

1. Créer des certificats utilisateur SSL

Cet exemple utilise des certificats auto-signés avec une CA auto-signée. Pour les environnements de production, créez une CSR et soumettez-la à votre équipe PKI ou à votre fournisseur de certificats afin d’obtenir un certificat approprié.

1. Générez une Certificate Signing Request (CSR) et une clé. Le format de base est le suivant :
   openssl req -newkey rsa:2048 -nodes -subj "/CN=<my_host>:<my_user>"  -keyout <my_cert_name>.key -out <my_cert_name>.csr
   
   Dans cet exemple, nous l’utiliserons pour le domaine et l’utilisateur qui seront utilisés dans cet environnement d’exemple :
   openssl req -newkey rsa:2048 -nodes -subj "/CN=chnode1.marsnet.local:cert_user"  -keyout chnode1_cert_user.key -out chnode1_cert_user.csr
   

Le CN est arbitraire et n’importe quelle chaîne peut être utilisée comme identifiant pour le certificat. Il est utilisé lors de la création de l’utilisateur dans les étapes suivantes.

2. Générez et signez le nouveau certificat utilisateur qui sera utilisé pour l’authentification. Le format de base est le suivant :
   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
   
   Dans cet exemple, nous l’utiliserons pour le domaine et l’utilisateur qui seront utilisés dans cet environnement d’exemple :
   openssl x509 -req -in chnode1_cert_user.csr -out chnode1_cert_user.crt -CA marsnet_ca.crt -CAkey marsnet_ca.key -days 365
   

​

2. Créer un utilisateur SQL et accorder des privilèges

Pour savoir comment activer les utilisateurs SQL et définir des rôles, consultez le guide Defining SQL Users and Roles.

1. Créez un utilisateur SQL configuré pour utiliser l’authentification par certificat :

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

2. Accordez des privilèges au nouvel utilisateur avec certificat :

   GRANT ALL ON *.* TO cert_user WITH GRANT OPTION;
   

Dans cet exercice, l’utilisateur reçoit tous les privilèges d’administration à des fins de démonstration. Consultez la documentation RBAC de ClickHouse pour les paramètres de permissions.

Nous recommandons d’utiliser SQL pour définir les utilisateurs et les rôles. Toutefois, si vous les définissez actuellement dans des fichiers de configuration, l’utilisateur se présentera comme suit :

<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>
        {/* options supplémentaires */}
    </cert_user>
</users>

​

3. Test

1. Copiez le certificat utilisateur, la clé utilisateur et le certificat de l’autorité de certification vers un nœud distant.

2. Configurez OpenSSL dans la configuration du client ClickHouse en indiquant le certificat et les chemins.

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

3. Exécutez clickhouse-client.

   clickhouse-client --user <my_user> --query 'SHOW TABLES'
   

Le mot de passe transmis à clickhouse-client est ignoré lorsqu’un certificat est spécifié dans la configuration.

​

4. Test HTTP

1. Copiez le certificat utilisateur, la clé utilisateur et le certificat de l’autorité de certification sur un nœud distant.

2. Utilisez curl pour tester un exemple de commande SQL. Le format de base est :

   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 @-
   

   Par exemple :

   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 @-
   

   Le résultat ressemblera à ceci :

   INFORMATION_SCHEMA
   default
   information_schema
   system
   

Notez qu’aucun mot de passe n’est spécifié : le certificat remplace le mot de passe, et c’est ainsi que ClickHouse authentifie l’utilisateur.

​

Résumé

Cet article a présenté les bases de la création et de la configuration d’un utilisateur pour l’authentification par certificat SSL. Cette méthode peut être utilisée avec clickhouse-client ou tout client prenant en charge l’interface https et permettant de définir des en-têtes HTTP. Le certificat et la clé générés doivent être conservés de façon sécurisée et avec un accès restreint, car le certificat sert à authentifier et à autoriser l’utilisateur pour des opérations sur la base de données ClickHouse. Traitez le certificat et la clé comme des mots de passe.