Skip to main content

​
FAQ

​
Quelles données quittent mon environnement ?

Deux composants envoient des données vers l’extérieur, tous deux via des connexions sortantes ouvertes par le connecteur lui-même : le chemin de collecte, qui transmet en continu des métadonnées opérationnelles, et les sessions d’assistance que vous activez, qui renvoient des diagnostics. Le collecteur envoie les résultats d’un ensemble fixe de tables système (metric_log, asynchronous_metric_log, tables, warnings, server_settings par défaut), des signaux périodiques d’intégrité et de statut, l’état de l’instance et des sauvegardes, ainsi que les propres métriques du connecteur. L’ensemble de collecte par défaut exclut délibérément system.query_log ; ainsi, le texte SQL brut, ainsi que les littéraux ou données personnelles qu’il contient, ne quitte jamais votre environnement par le chemin de collecte, sauf si vous l’ajoutez explicitement. Pendant une session, la liste d’autorisation des tables par défaut inclut system.processes, qui affiche le texte des requêtes en cours ; retirez-la de la liste d’autorisation si ces informations doivent rester masquées. Lors d’une session d’assistance active, l’outil de dépannage renvoie également la sortie des commandes, limitée aux tables ClickHouse figurant dans la liste d’autorisation et aux vues Kubernetes en lecture seule, y compris les logs des pods, et soumise à la suppression des informations sensibles (patterns intégrés pour les adresses IP, les identifiants, les tokens et les clés, ainsi que les vôtres) avant son envoi. Vos données de table, sauvegardes et historique des requêtes (system.query_log, system.text_log) restent systématiquement dans votre environnement. Les exceptions documentées sont les suivantes : les lignes des tables d’historique des métriques figurant dans la liste d’autorisation (system.metric_log, system.asynchronous_metric_log) sont envoyées à chaque collecte, le texte des requêtes en cours est visible pendant la session via system.processes sauf si vous le retirez de la liste d’autorisation, et les logs des pods lus lors d’une session d’assistance Kubernetes quittent votre environnement après suppression des informations sensibles. La liste complète des connexions sortantes figure sur la page du modèle de privilèges.

​
Comment révoquer l’accès de ClickHouse ?

Par ordre croissant de radicalité :
  1. Mettre fin à l’accès interactif. Désactivez la session : sudo clicklink clctl troubleshoot session disable sur l’hôte de la VM, ou exécutez la même commande avec --gateway-url via le port-forward sur Kubernetes (les commandes exactes figurent sur la page des sessions d’assistance). En l’absence de session active, l’outil de dépannage refuse toutes les commandes, même lorsqu’il est connecté.
  2. Empêcher toute session ultérieure. Videz la liste d’autorisation des opérateurs (une liste vide ferme la passerelle) ou désactivez la passerelle ; sur une VM, la gestion locale des sessions reste accessible à root sur l’hôte. Consultez le guide de configuration.
  3. Couper la connectivité avec ClickHouse Cloud. Bloquez le trafic sortant vers l’endpoint de votre connecteur au niveau réseau, ou videz networkPolicy.allowEgressCIDRs avec un CNI appliquant les règles ; le connecteur est uniquement sortant, donc ClickHouse Cloud ne dispose d’aucun chemin entrant pour le rétablir. Les lectures locales sur votre instance ClickHouse se poursuivent jusqu’à ce que vous arrêtiez ou désinstalliez les workloads, ce qui constitue l’arrêt complet.
  4. Révoquer les identifiants d’accès. Supprimez les utilisateurs ClickHouse pcm_scraper et pcm_troubleshooter, puis supprimez les Secrets du connecteur (Kubernetes) ou les fichiers sous /etc/clicklink (VM).
  5. Supprimer entièrement le connecteur. Consultez les opérations.

​
Puis-je exécuter cette solution dans un environnement isolé du réseau ou via mes propres miroirs ?

Oui. Chaque artefact requis lors de l’installation peut provenir de votre périmètre : mettez en miroir l’archive tar de la CLI et l’image de conteneur depuis releases.clicklink.clickhouse.com et le registre public, pointez image.repository vers votre miroir et transmettez --chart avec une référence oci://, une URL ou une archive locale (avec --chart-version ; par défaut, il utilise la version de la CLI). Si le point de terminaison de l’API de votre connecteur est exposé au sein de votre périmètre derrière une CA privée, --api-private-ca (Kubernetes) ou api.tls.ca_file (VM) le vérifie par rapport à la chaîne du bundle d’inscription. Pour l’inscription sans connectivité directe, init --handoff utilise un bundle obtenu hors bande, tandis que --no-auto-sign associé à init --signed-cert permet d’effectuer la signature du certificat hors bande. Consultez les miroirs privés et la section sur les environnements isolés du réseau de l’onboarding. Notez que le connecteur doit tout de même disposer, à l’exécution, d’une route vers le point de terminaison de l’API du connecteur de votre organisation ; sans cela, ClickHouse Cloud ne reçoit aucune télémétrie.

​
Que se passe-t-il si le connecteur tombe en panne ?

Vos services ClickHouse ne sont pas affectés : le connecteur se contente d’y lire des données et ne se trouve sur aucun chemin de données. Cela entraîne une perte de visibilité : ClickHouse Cloud cesse de recevoir de la télémétrie et les sessions d’assistance deviennent indisponibles jusqu’à son rétablissement. Sur une VM, le collecteur met en mémoire tampon les données récupérées dans /var/lib/clicklink/buffer (jusqu’à 168 heures ou 1 024 Mo par défaut) lorsque le point de terminaison de l’API est inaccessible, puis les transmet lors de la reconnexion. Une indisponibilité du point de terminaison n’entraîne donc aucune perte de télémétrie. Un démon qui se bloque est redémarré par systemd et, sur Kubernetes, par le kubelet. Pour diagnostiquer le problème, vérifiez le point de terminaison /livez de chaque composant (le champ JSON status fait foi, pas le code HTTP) et exécutez clicklink clctl preflight (avec sudo sur l’hôte VM), qui vérifie en une seule passe la configuration, la connectivité, l’accessibilité de ClickHouse, les accès et le disque. Consultez les opérations ; si le connecteur reste défaillant, contactez ClickHouse Support.

​
Comment les sessions d’assistance sont-elles auditées ?

Chaque appel de passerelle et chaque commande de dépannage, qu’ils soient acceptés ou bloqués, sont ajoutés à un journal d’audit au format JSON délimité par des sauts de ligne dans /var/log/clicklink/troubleshoot-audit.log, avec une attribution par entrée : les appels de passerelle incluent l’adresse e-mail de l’opérateur attestée par le jeton (jamais un nom déclaré par l’utilisateur), les modifications des sessions locales de VM enregistrent l’utilisateur hôte à l’origine de l’appel, et les commandes exécutées durant une session enregistrent l’identité de l’org sur le canal authentifié. Les sessions elles-mêmes sont limitées dans le temps (4 heures par défaut, 24 heures au maximum) et chaque activation enregistre la personne qui l’a activée, sa date d’expiration et un motif facultatif, informations affichées par clicklink clctl troubleshoot session status. Lisez le journal avec clicklink clctl troubleshoot audit tail ; sur Kubernetes, cette commande est le lecteur pris en charge (l’image d’exécution ne contient pas de shell) et, avec le paramètre par défaut persistence.enabled: true, le journal est stocké sur le volume persistant de l’outil de dépannage afin que la trace soit conservée après le réordonnancement des pods. La désactivation de la persistance limite le journal d’audit et l’état de session à la durée de vie du pod, ce que le chart indique comme étant adapté uniquement au développement local. Par défaut, la rotation conserve 5 fichiers de 128 Mo maximum pendant 168 heures ; consultez la référence de configuration pour l’ajuster, ainsi que les sessions d’assistance pour connaître le modèle de confiance complet.
Dernière modification le 26 août 2026