Skip to main content
Cette page présente les modifications de configuration les plus courantes après l’installation de ClickHouse Connector. Pour chaque clé, sa valeur par défaut et sa signification, consultez la référence de configuration ; pour les options de ligne de commande, consultez la référence CLI.

Points de configuration

Le connecteur dispose d’un point de configuration pour chaque cible d’installation.
clicklink clctl init crée, dans le répertoire de travail, un fichier de valeurs de surcharge nommé clicklink-values.yaml, puis déploie le chart clicklink-connector avec celui-ci. Ce fichier de surcharge constitue la trace persistante de votre déploiement : relancer init le conserve, sauf si vous passez --force, afin que vos modifications soient préservées lors des nouvelles exécutions et de la récupération.
Les commandes d’exploitation de cette page et de la page opérations utilisent la CLI helm. Seule init intègre un client Helm.
Modifiez le fichier de surcharge, puis appliquez-le :
Ce bloc réapplique vos valeurs modifiées à la version du chart déjà installée, afin qu’une modification de configuration ne déclenche jamais une mise à niveau imprévue ; le passage à une nouvelle version est une étape volontaire décrite dans les opérations. Pour une installation en miroir utilisant un dépôt de charts, remplacez --repo par votre miroir.Une installation à partir d’une référence directe de chart (oci://, une URL, une archive locale ou un répertoire local ; voir miroirs privés) ne dispose d’aucun dépôt permettant de résoudre cette référence. Relancez la mise à niveau avec la référence utilisée lors de l’installation :

Ajout ou modification d’instances ClickHouse

Chaque entrée sous instances désigne un point de terminaison du protocole natif ClickHouse à partir duquel le connecteur lit les données : host, port, database, secure, ainsi que namespace et cluster sur Kubernetes. Les identifiants ne figurent jamais dans la configuration ; chaque composant récupère son utilisateur ClickHouse en lecture seule depuis le bundle d’accès créé lors du provisionnement.
Ajoutez l’instance aux mappages des deux composants dans clicklink-values.yaml, puis ajoutez son espace de noms à networkPolicy.clickhouseNamespaces (mis en correspondance via le label kubernetes.io/metadata.name de l’espace de noms) :
Provisionnez un accès en lecture seule pour chaque composant depuis votre poste de travail. --apply-ch-grants applique les autorisations ClickHouse générées dans le pod via kubectl exec ; sans cette option, la commande crée uniquement les ressources Kubernetes et laisse ch-grants.sql sur le disque afin que vous l’appliquiez. Si l’utilisateur admin possède un mot de passe, ajoutez --ch-admin-password-stdin et transmettez-le par un pipe.
Pour une instance gérée par un operator ne disposant pas d’un administrateur capable d’exécuter du SQL, remplacez --apply-ch-grants par --ch-user-via cr (les options de sélection du pod restent les mêmes) ; consultez la référence CLI. Référencez ensuite la paire Secret et ServiceAccount créée par chaque commande dans le mappage accessBundles correspondant, puis exécutez la commande helm upgrade indiquée ci-dessus :
Les mêmes commandes access provision, avec --force, renouvellent les identifiants ClickHouse d’une instance. Consultez la page opérations.

Liste d’autorisation des opérateurs

Les sessions gérées par la passerelle sont soumises à une liste d’autorisation d’adresses e-mail d’opérateurs : chaque requête envoyée à la passerelle de sessions doit inclure un jeton d’identité OIDC à courte durée de vie dont l’adresse e-mail attestée figure dans cette liste. Une liste d’autorisation vide ferme la passerelle : personne ne peut alors ouvrir de session via celle-ci. Sur une VM, root sur l’hôte peut également gérer les sessions directement via le fichier de sessions local ; la liste d’autorisation ne régit que le chemin passant par la passerelle. Consultez les sessions de support pour connaître le modèle de confiance complet.
La liste d’autorisation se trouve dans le fichier de surcharge et est générée dans une ConfigMap. Pour la modifier, éditez la liste et exécutez helm upgrade :

Politique réseau et trafic sortant

Sur Kubernetes, le chart fournit une ressource NetworkPolicy qui bloque le trafic par défaut, avec une liste d’autorisation pour le trafic sortant (networkPolicy.enabled: true). Les objets NetworkPolicy ne prennent effet que si votre CNI les applique. Avec un CNI qui les applique, le connecteur ne dispose d’aucun trafic sortant tant que allowEgressCIDRs ne spécifie pas les CIDR correspondant au point de terminaison de l’API de votre connecteur.
Deux règles requièrent une attention particulière :
  • apiserverCIDRs : s’il est vide, le chart n’émet aucune règle de trafic sortant pour le serveur API. Les démons échouent alors lors de leur première requête de jeton Kubernetes avec une erreur réseau, ce qui indique qu’il doit être défini. Sur Kubernetes géré, utilisez le ou les CIDR de l’endpoint du serveur API du cluster.
  • clctl.gateway.jwksEgressCIDRs : lorsque la passerelle de sessions est activée, l’outil de dépannage récupère les JWKS de votre fournisseur d’identité afin de valider les jetons d’opérateur. Dans le cadre d’une politique de refus par défaut, le laisser vide bloque toute vérification de jeton :
La plage private.googleapis.com couvre un fournisseur d’identité Google accessible via Private Google Access ; pour tout autre fournisseur d’identité, indiquez la plage correspondante (ou le CIDR du proxy d’egress situé devant celui-ci). Deux autres paramètres d’Ingress : metricsScrapeSelector restreint l’Ingress de collecte des métriques à un espace de noms Prometheus spécifique via un label, et kubeletProbeCIDRs autorise explicitement les sondes de santé du kubelet dans les environnements où le refus par défaut est strict. Consultez la référence de configuration pour obtenir la liste complète des clés.

Motifs de masquage

La sortie de Troubleshooter est masquée avant de quitter votre périmètre. Les motifs intégrés couvrent ipv4, ipv6, bearer-token, aws-access-key, email, jwt, ssh-private-key et connection-string-credentials. Vous pouvez ajouter vos propres motifs dans un fichier YAML ; ils sont appliqués en premier, dans l’ordre du fichier, suivis des motifs intégrés. Une entrée qui réutilise le name d’un motif intégré remplace ce dernier. Chaque motif accepte name (obligatoire, unique), regex (obligatoire, syntaxe RE2 de Go), replace (par défaut [REDACTED], prend en charge les références de capture $1) et case_insensitive (par défaut false) :
Sur une VM, le fichier est /etc/clicklink/redaction-patterns.yaml ; l’installateur crée une configuration par défaut commentée et conserve votre version lors des mises à niveau. Dans Kubernetes, placez le YAML dans une ConfigMap sous la clé redaction-patterns.yaml et définissez troubleshooter.redaction.patternsConfigMap sur son nom ; le chart le monte au même chemin.
L’outil de dépannage refuse de démarrer lorsqu’un fichier de patterns est présent mais non valide, et consigne l’entrée en cause. clicklink clctl preflight valide le fichier ; exécutez-le avant de redémarrer le démon.

Miroirs privés et endpoints internes au périmètre

Le chart publié définit par défaut image.repository sur l’image publique multi-architecture du connecteur, signée avec cosign ; les installations standard ne nécessitent donc aucune valeur d’image. Pour consulter les valeurs par défaut publiées :
Pour utiliser votre propre registre, remplacez le dépôt dans le fichier de surcharge :
Pour installer le chart depuis un miroir, init accepte --chart sous la forme d’un nom de chart résolu à partir de --chart-repo, ou d’une référence oci:// directe, d’une URL, d’une archive locale ou d’un répertoire local. Par défaut, --chart-version utilise la version de la CLI afin que le binaire et le chart évoluent de concert :
Lorsque le point de terminaison de l’API de votre connector se trouve derrière une CA privée au sein de votre périmètre, transmettez --api-private-ca à init : cette option configure api.tls.caFile: /etc/clicklink/secrets/mtls/ca.crt, afin que le point de terminaison de l’API soit vérifié par rapport à la chaîne de CA de votre bundle d’onboarding plutôt qu’aux racines système. Sur une VM, l’équivalent est api.tls.ca_file dans /etc/clicklink/config.yaml ; init installe la chaîne du bundle dans /etc/clicklink/tls/ca.crt et l’ajoute aux racines système pour la vérification. Pour un onboarding entièrement air-gapped et la signature de certificats, consultez l’onboarding.

Stockage

L’utilitaire de dépannage conserve son état dans un PersistentVolumeClaim, afin que l’état de session et la piste d’audit soient préservés lors de la replanification des pods :
Une storageClass vide utilise la StorageClass par défaut du cluster. Si le cluster n’en définit aucune par défaut, init en requiert une, via l’invite ou --storage-class.
Dernière modification le 26 août 2026