Configuration de l'authentification à l'aide d'un certificat utilisateur 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.

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é.

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.

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

Créer un utilisateur SQL et accorder des autorisations

Pour plus de détails sur la manière d’activer les utilisateurs SQL et de définir des rôles, consultez le guide d’utilisation Defining SQL Users and Roles.

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';

Accordez des privilèges au nouvel utilisateur authentifié par 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 d’autorisations.

Nous recommandons d’utiliser SQL pour définir les utilisateurs et les rôles. Cependant, si vous définissez actuellement les utilisateurs et les rôles dans des fichiers de configuration, l’utilisateur ressemblera à ceci :

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

Test

Copiez le certificat utilisateur, la clé utilisateur et le certificat de la CA sur un nœud distant.

Configurez OpenSSL dans la configuration du client de ClickHouse avec le certificat et les chemins correspondants.

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

Exécutez clickhouse-client.

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

Notez que le mot de passe transmis à clickhouse-client est ignoré lorsqu’un certificat est spécifié dans la config.

Test HTTP

Copiez le certificat utilisateur, la clé utilisateur et le certificat de la CA vers un nœud distant.

Utilisez curl pour tester une commande SQL d’exemple. Le format de base est le suivant :

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

La sortie sera similaire à ce qui suit :

INFORMATION_SCHEMA
default
information_schema
system

Notez qu’aucun mot de passe n’est spécifié : le certificat est utilisé à la place d’un 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.

​Résumé

Résumé