> ## Documentation Index > Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Configuration > Configurez ClickHouse Connector : instances ClickHouse, listes d’autorisation d’opérateurs, politique réseau, masquage, miroirs privés et stockage 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](/docs/fr/products/bring-your-own-cloud/connector/reference/configuration) ; pour les options de ligne de commande, consultez la [référence CLI](/docs/fr/products/bring-your-own-cloud/connector/reference/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](/docs/fr/products/bring-your-own-cloud/connector/operations) utilisent la CLI `helm`. Seule `init` intègre un client Helm. Modifiez le fichier de surcharge, puis appliquez-le : ```bash theme={null} CONNECTOR_NAMESPACE='clicklink' # l'espace de noms du connecteur choisi lors de l'initialisation CHART_VERSION="$(helm get metadata clicklink-connector -n "${CONNECTOR_NAMESPACE}" | awk '/^VERSION:/{print $2}')" helm upgrade clicklink-connector clicklink-connector \ --repo https://releases.clicklink.clickhouse.com/charts \ --version "${CHART_VERSION}" \ --namespace "${CONNECTOR_NAMESPACE}" \ -f clicklink-values.yaml ``` 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](/docs/fr/products/bring-your-own-cloud/connector/operations). 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](#private-mirrors)) 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 : ```bash theme={null} helm upgrade clicklink-connector \ --version "${CHART_VERSION}" \ -n "${CONNECTOR_NAMESPACE}" \ -f clicklink-values.yaml ``` `clicklink clctl init` écrit dans `/etc/clicklink/config.yaml`. Relancer `init` conserve une configuration existante, sauf si vous passez `--force` ; vous pouvez donc modifier ce fichier manuellement en toute sécurité. Après l'avoir modifié, redémarrez les démons et vérifiez : ```bash theme={null} sudo systemctl restart clicklink-scraper clicklink-troubleshooter sudo clicklink clctl preflight ```
## 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) : ```yaml theme={null} scraper: instances: analytics: host: "clickhouse-analytics.clickhouse.svc.cluster.local" port: 9440 database: "default" secure: true namespace: "clickhouse" cluster: "default" troubleshooter: instances: analytics: host: "clickhouse-analytics.clickhouse.svc.cluster.local" port: 9440 database: "default" secure: true namespace: "clickhouse" cluster: "default" networkPolicy: clickhouseNamespaces: - "clickhouse" ``` 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. ```bash theme={null} CONNECTOR_NAMESPACE='clicklink' # l'espace de noms du connecteur choisi lors de l'initialisation clicklink clctl scraper access provision --target helm \ --target-namespace "${CONNECTOR_NAMESPACE}" \ --instance analytics --instance-namespace clickhouse \ --server \ --apply-ch-grants --ch-pod --ch-pod-namespace clickhouse clicklink clctl troubleshoot access provision --target helm \ --target-namespace "${CONNECTOR_NAMESPACE}" \ --instance analytics --instance-namespace clickhouse \ --server \ --apply-ch-grants --ch-pod --ch-pod-namespace clickhouse ``` 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](/docs/fr/products/bring-your-own-cloud/connector/reference/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 : ```yaml theme={null} scraper: accessBundles: analytics: secretName: clicklink-connector-scraper-access-analytics serviceAccountName: pcm-scraper-analytics troubleshooter: accessBundles: analytics: secretName: clicklink-connector-troubleshooter-access-analytics serviceAccountName: pcm-troubleshooter-analytics ``` Ajoutez l'instance à `/etc/clicklink/config.yaml` : ```yaml theme={null} instances: analytics: host: "10.0.12.34" port: 9440 database: "default" secure: true cluster: "default" ``` Provisionnez ensuite l'accès pour chaque composant sur l'hôte en tant que root. Chaque commande applique les autorisations ClickHouse et redémarre son démon (omettez le redémarrage avec `--skip-restart`) : ```bash theme={null} sudo clicklink clctl scraper access provision --provider local \ --instance analytics --server sudo clicklink clctl troubleshoot access provision --provider local \ --instance analytics --server ``` Les mêmes commandes `access provision`, avec `--force`, renouvellent les identifiants ClickHouse d'une instance. Consultez la page [opérations](/docs/fr/products/bring-your-own-cloud/connector/operations).
## 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](/docs/fr/products/bring-your-own-cloud/connector/support-sessions) 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` : ```yaml theme={null} clctl: gateway: enabled: true allowedOperators: - "oncall@example.com" - "dba@example.com" ``` `init` écrit la liste d'autorisation dans `/etc/clicklink/allowed-operators.txt`, à raison d'une adresse e-mail par ligne : ```text theme={null} oncall@example.com dba@example.com ``` L'outil de dépannage relit le fichier toutes les 30 secondes ; les modifications prennent donc effet sans redémarrage.
## 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. ```yaml theme={null} networkPolicy: enabled: true # CIDRs behind your connector API endpoint. Required under an enforcing CNI. allowEgressCIDRs: - "203.0.113.0/24" # Ports opened to allowEgressCIDRs. allowEgressPorts: - 443 # Namespaces of your ClickHouse Services, matched by the # kubernetes.io/metadata.name label. Empty allows no in-cluster # ClickHouse access. clickhouseNamespaces: - "clickhouse" # Kubernetes API server CIDRs. On managed Kubernetes the API server sits # outside the cluster network, so it cannot be matched with a selector. apiserverCIDRs: - "172.16.0.0/28" ``` 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 : ```yaml theme={null} clctl: gateway: jwksEgressCIDRs: - "199.36.153.8/30" ``` 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](/docs/fr/products/bring-your-own-cloud/connector/reference/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`) : ```yaml theme={null} version: 1 patterns: - name: internal-hostname regex: '\b[a-z0-9-]+\.corp\.example\.com\b' replace: '[REDACTED:internal-host]' # Reusing a built-in name replaces the built-in pattern. - name: ipv4 regex: '\b(?:\d{1,3}\.){3}\d{1,3}\b' replace: '[REDACTED:ip]' ``` 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 : ```bash theme={null} CLICKLINK_VERSION="$(curl -fsSL https://releases.clicklink.clickhouse.com/latest-version.txt)" helm show values clicklink-connector \ --repo https://releases.clicklink.clickhouse.com/charts \ --version "${CLICKLINK_VERSION#v}" ``` Pour utiliser votre propre registre, remplacez le dépôt dans le fichier de surcharge : ```yaml theme={null} image: repository: "registry.example.com/mirrors/clicklink" ``` 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 : ```bash theme={null} clicklink clctl init --handoff handoff.yaml --target helm \ --chart oci://registry.example.com/charts/clicklink-connector ``` 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](/docs/fr/products/bring-your-own-cloud/connector/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 : ```yaml theme={null} persistence: enabled: true storageClass: "gp3" size: 5Gi ``` 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`. Le scraper met les métriques en mémoire tampon dans `/var/lib/clicklink/buffer` afin de garantir une livraison au moins une fois lorsque le point de terminaison de l’API est inaccessible. Il les conserve jusqu'à 168 heures ou 1024 Mo et les téléverse à un débit limité à 1 Mo/s par défaut : ```yaml theme={null} scraper: buffer: path: /var/lib/clicklink/buffer retention: 168h max_size_mb: 1024 ``` `clicklink clctl preflight` inclut des vérifications du disque pour le répertoire de mémoire tampon et `/var/log`.