Skip to main content

​
Connexions entre le plan de contrôle ClickHouse et votre VPC BYOC

Le plan de contrôle ClickHouse Cloud maintient plusieurs types de connexions pour faire fonctionner et prendre en charge votre déploiement BYOC :

​
API des fournisseurs de Cloud et API Kubernetes

Il est facile de confondre deux chemins de contrôle distincts. Ils diffèrent par l’origine du trafic, son mode d’authentification et la possibilité ou non d’utiliser Tailscale : En bref : seuls l’API Kubernetes et le trafic de dépannage peuvent utiliser Tailscale. Les appels de gestion décrits ci-dessus proviennent toujours du réseau de ClickHouse Cloud et aboutissent aux points de terminaison du fournisseur ; il est impossible de les router via Tailscale, car ils n’entrent jamais dans votre réseau. Les API des fournisseurs de Cloud sont également appelées dans l’autre sens, par des contrôleurs s’exécutant au sein de votre propre cluster — le contrôleur de répartition de charge, le pilote CSI, l’autoscaler, le contrôleur DNS et cert-manager. Ces appels utilisent des identités internes au cluster et sortent par votre propre chemin de sortie ; ils apparaissent donc dans votre piste d’audit sous une identité et une adresse source différentes de celles des appels de gestion. Voir Connexions sortantes.

​
Limites d’autorisation selon l’origine réseau

Si votre organisation limite l’utilisation d’un rôle IAM ou les appels aux API Cloud en fonction de l’origine réseau (par exemple, via des SCP AWS ou des conditions de confiance de rôle utilisant aws:SourceIp ou aws:SourceVpc), ces conditions bloqueront l’automatisation de ClickHouse : les appels proviennent légitimement du réseau de ClickHouse Cloud, et non du vôtre. Exemptez les rôles créés par ClickHouse de ces conditions ou contactez ClickHouse pour obtenir les plages d’adresses IP d’egress actuelles si vous devez utiliser une allowlist selon l’origine. La section suivante explique comment le réseau privé Tailscale est utilisé pour le dépannage et l’accès de gestion facultatif.

​
Réseau privé Tailscale

Tailscale fournit une connexion réseau privée de type zero trust entre les services de gestion de ClickHouse Cloud et votre déploiement BYOC. Ce canal sécurisé permet aux ingénieurs ClickHouse d’effectuer des opérations de dépannage et de gestion sans nécessiter d’accès entrant au réseau public ni de configurations VPN complexes ; les agents eux-mêmes établissent uniquement des connexions sortantes et nécessitent un accès Internet sortant pour atteindre le service de coordination Tailscale.

​
Vue d’ensemble

Tailscale crée un tunnel réseau privé et chiffré entre le plan de contrôle de ClickHouse (dans le VPC de ClickHouse) et votre plan de données BYOC (dans votre VPC). Cette connexion est utilisée exclusivement pour :
  • Opérations de gestion : les services de gestion de ClickHouse se coordonnent avec votre infrastructure BYOC
  • Accès de dépannage : les ingénieurs ClickHouse accèdent aux serveurs d’API Kubernetes et aux tables système ClickHouse à des fins de diagnostic
  • Accès aux métriques : les dashboards de monitoring centralisés de ClickHouse accèdent aux métriques de la stack Prometheus déployée dans votre VPC BYOC, offrant aux ingénieurs ClickHouse une visibilité sur l’environnement.
Tailscale est utilisé uniquement pour les opérations de gestion et de dépannage. Il n’est jamais utilisé pour le trafic de requêtes ni pour l’accès aux données client. Toutes les données client restent dans votre propre compte cloud et ne sont jamais transmises via des connexions Tailscale.

​
Fonctionnement de Tailscale dans BYOC

Pour chaque service ou point de terminaison qui doit être accessible via Tailscale, ClickHouse BYOC déploie :
  1. Enregistrement de l’adresse tailnet : chaque point de terminaison enregistre une adresse tailnet unique (par ex., k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com pour le serveur d’API Kubernetes)
  2. Conteneur d’agent Tailscale : un conteneur d’agent Tailscale s’exécute dans votre cluster Kubernetes et se charge de :
    • Se connecter au serveur de coordination Tailscale
    • Enregistrer les services afin de les rendre détectables
    • Coordonner la configuration réseau avec les pods Nginx
  3. Pod Nginx : un pod Nginx qui :
    • Termine le trafic TLS provenant de Tailscale
    • Achemine le trafic vers les adresses IP appropriées au sein de votre cluster Kubernetes

​
Processus de connexion réseau

L’établissement de la connexion Tailscale suit les étapes suivantes :
  1. Connexion initiale :
    • Les agents Tailscale aux deux extrémités (l’environnement de l’ingénieur ClickHouse et votre cluster Kubernetes BYOC) se connectent au serveur de coordination Tailscale
    • L’agent du cluster enregistre le service Kubernetes afin qu’il puisse être découvert
    • Les ingénieurs ClickHouse doivent faire remonter la demande en interne pour obtenir la visibilité sur le service
  2. Mode de connexion :
    • Mode direct : les agents tentent d’établir une connexion directe au moyen d’un tunnel de traversée de NAT
    • Mode relais : si le mode direct échoue, la communication bascule vers le mode relais via un serveur DERP (Distributed Encrypted Relay Protocol) de Tailscale
  3. Chiffrement :
    • Toutes les communications sont chiffrées de bout en bout
    • Chaque agent Tailscale génère sa propre paire de clés publique-privée (semblable à une PKI)
    • Le trafic reste chiffré, qu’il passe par le mode direct ou le mode relais

​
Fonctionnalités de sécurité

Connexions sortantes uniquement :
  • Les agents Tailscale de votre cluster Kubernetes établissent des connexions sortantes vers les serveurs de coordination/relais Tailscale
  • Aucune connexion entrante n’est requise — aucune règle de groupe de sécurité ne doit autoriser le trafic entrant vers les agents Tailscale
  • Cela réduit la surface d’attaque et simplifie la configuration de la sécurité réseau
Contrôle d’accès :
  • Les ingénieurs doivent demander l’accès via un processus d’approbation interne avant que Tailscale puisse acheminer leur connexion vers un point de terminaison client
  • L’accès est limité dans le temps et expire automatiquement
  • Tous les accès font l’objet d’un audit et sont journalisés
Pour la politique complète d’accès aux données — ce que les ingénieurs peuvent voir, l’authentification basée sur des certificats et l’audit côté client — consultez ClickHouse data access.

​
Accès aux services de gestion

Par défaut, les services de gestion de ClickHouse accèdent à votre cluster Kubernetes BYOC via le point de terminaison public du serveur d’API, que chaque cloud protège différemment : sur AWS par une IP allow list ne contenant que les adresses de la NAT gateway de ClickHouse, sur GCP et Azure par l’IAM du cloud. Voir Exposition du serveur d’API Kubernetes pour le détail par cloud. Configuration facultative d’un point de terminaison privé :
  • Vous pouvez configurer le serveur d’API Kubernetes pour qu’il utilise uniquement un point de terminaison privé
  • Dans ce cas, les services de gestion accèdent au serveur API via Tailscale (de la même manière que pour l’accès de dépannage des intervenants humains) ou, sur AWS, via VPC Lattice (voir Connexion privée à l’API Kubernetes)
  • Par défaut, le point de terminaison public est conservé comme mécanisme de secours pour les besoins d’investigation d’urgence et de support ; une fois l’accès privé vérifié, il peut être entièrement désactivé en coordination avec ClickHouse

​
Flux du trafic réseau

Cheminement de la connexion Tailscale :
  1. agent Tailscale dans votre cluster Kubernetes → serveur de coordination Tailscale (sortant)
  2. agent Tailscale sur la machine de l’ingénieur → serveur de coordination Tailscale (sortant)
  3. Connexion directe ou relayée établie entre les agents
  4. Le trafic chiffré transite par le tunnel établi
  5. Le pod Nginx dans votre cluster Kubernetes assure la terminaison TLS et achemine le trafic vers les services internes
Aucune transmission de données client :
  • Les connexions Tailscale sont utilisées uniquement pour la gestion et le dépannage
  • Le trafic des requêtes et les données client ne transitent jamais par Tailscale
  • Toutes les données client restent dans votre propre compte cloud
Pour plus de détails techniques sur l’implémentation de Tailscale dans BYOC, consultez l’article de blog Building ClickHouse BYOC on AWS. Pour savoir quelles données les ingénieurs ClickHouse peuvent consulter une fois connectés et comment ClickHouse audite cet accès, consultez ClickHouse data access.

​
Frontières réseau

Cette section présente la vue firewall d’un déploiement BYOC : chaque connection qui franchit la frontière de votre réseau BYOC, dans un sens comme dans l’autre. Elle s’applique à AWS, GCP et Azure ; lorsque les clouds se comportent différemment, le cloud concerné est explicitement nommé. Termes employés dans cette section :
  • Inbound : trafic entrant dans votre réseau BYOC — un VPC sur AWS, un réseau VPC sur GCP ou un VNet sur Azure.
  • Outbound : trafic provenant de votre réseau BYOC et envoyé vers une destination externe.
  • Public : un endpoint joignable depuis l’Internet public.
  • Private : un endpoint joignable uniquement via un chemin privé — peering VPC/VNet, AWS PrivateLink, GCP Private Service Connect, Azure Private Link ou Tailscale.

​
Équivalents par fournisseur

Le reste de cette page utilise une terminologie indépendante du cloud. Ce tableau établit la correspondance avec chaque fournisseur : L’egress vers l’Internet public quitte votre réseau BYOC par un ensemble restreint et fixe d’adresses NAT, quel que soit le cloud, ce qui vous permet de les déclarer dans vos propres contrôles d’egress. Demandez à votre ClickHouse team les valeurs actuelles correspondant à votre déploiement. Sur AWS et GCP, le trafic vers les storage APIs du fournisseur lui-même fait exception : il emprunte le chemin privé indiqué dans la ligne ci-dessus et n’atteint jamais la passerelle NAT.

​
Connexions entrantes

Deux ports sont parfois visibles sur ces load balancers, mais ne sont pas destinés aux clients : le port TCP 15021 sert aux contrôles de santé propres au fournisseur sur l’ingress gateway et ne transporte aucun trafic de requêtes ; quant à l’interface MySQL (port 3306), elle n’est pas exposée pour l’instant en BYOC — voir la FAQ. Le certificat de l’ingress gateway est émis par cert-manager depuis une certificate authority ACME publique (Let’s Encrypt) au moyen d’une validation DNS-01, et il est stocké sous forme de Kubernetes secret dans votre propre cluster. Le trafic entre l’ingress gateway et les pods ClickHouse ne quitte pas votre réseau BYOC — voir Trafic intra-réseau. Le load balancer activé par défaut dépend de votre modèle réseau. Avec un VPC géré par ClickHouse, chaque service dispose du public load balancer, protégé par une IP access list, et le private load balancer peut être activé en complément. Avec un VPC customer-managed, les valeurs par défaut s’inversent : seul le private load balancer est activé et vos services n’exposent aucune surface d’entrée publique, sauf si vous en ajoutez une. Voir Se connecter à votre service BYOC. Partout où le chemin public est activé, nous recommandons fortement de configurer un filtre IP ; vous pouvez également ajouter un chemin privé — voir Private networking setup — puis désactiver entièrement l’accès public. Notez que le filtrage IP est appliqué au niveau de la couche proxy d’entrée : les ports du load balancer peuvent donc apparaître ouverts lors d’un scan alors même que les connexions provenant de sources non listées sont rejetées.
En dehors des listeners ci-dessus, il n’y a ni SSH, ni hôte bastion, ni identifiant administratif permanent. Le trafic de requêtes ne traverse jamais l’infrastructure détenue par ClickHouse, dans aucun sens : vos clients se connectent directement à l’entrée située dans votre propre réseau.Des ports de protocole supplémentaires peuvent être activés selon le déploiement — l’accès natif authentifié par certificat et Arrow Flight en sont les exemples actuels — vérifiez donc l’ensemble exact des ports de votre déploiement auprès de votre équipe ClickHouse avant de rédiger des règles de pare-feu à partir de ce tableau.

​
Exposition du serveur d’API Kubernetes

La manière dont les services de gestion de ClickHouse joignent le serveur d’API Kubernetes, ainsi que les restrictions appliquées à cet access, varient selon le cloud :
  • AWS (EKS) : le public endpoint est restreint aux plages CIDR d’egress de ClickHouse via la liste CIDR d’accès public du cluster. Il peut être basculé en accès privé uniquement via Tailscale ou VPC Lattice — voir Kubernetes API Private Connection.
  • GCP (GKE) : les nœuds sont toujours privés. Le plan de contrôle est joignable via son endpoint basé sur DNS (*.gke.goog), autorisé par la permission IAM container.clusters.connect sur le compte de service usurpé plutôt que par une IP allow list. La request se termine au niveau du frontend de Google et non à l’intérieur de votre réseau VPC, mais il s’agit tout de même d’un chemin d’access vers le plan de contrôle de votre cluster : examinez-le donc comme un accès entrant. Le public endpoint distinct basé sur IP peut être désactivé, l’endpoint basé sur DNS devenant alors l’unique chemin vers le plan de contrôle — voir Kubernetes API Private Connection.
  • Azure (AKS) : le serveur d’API Kubernetes est joignable via son FQDN public et autorisé par Microsoft Entra ID conjointement avec Azure RBAC. Les plages IP autorisées pour le serveur d’API Kubernetes ne sont pas appliquées par défaut ; contactez ClickHouse si votre policy l’exige. Le cluster peut également être créé en tant que cluster privé, joignable via Azure Private Link et dont le FQDN public est désactivé — voir Kubernetes API Private Connection.
Seuls le trafic de la Kubernetes API et le trafic de troubleshooting peuvent être basculés sur un chemin privé. Les appels de management vers les API de votre cloud provider proviennent du réseau de ClickHouse Cloud et ne peuvent pas y être routés — voir API des cloud providers vs Kubernetes API, qui couvre également les appels à l’API du provider effectués par les controllers au sein de votre propre cluster.

​
Accès de dépannage

Inbound, Private Les ingénieurs ClickHouse Cloud accèdent à votre déploiement à des fins de dépannage uniquement via Tailscale, jamais par l’Internet public, et ce sur tous les clouds. L’accès est just-in-time et repose sur des certificats : l’ingénieur en fait la demande via un workflow d’approbation interne, la plateforme génère un credential éphémère propre à cet ingénieur, lequel expire automatiquement. Il n’existe aucune identité administrative partagée ni aucun accès permanent. Consultez ClickHouse data access pour connaître la politique complète, y compris les tables que les ingénieurs peuvent lire.

​
Connexions sortantes

​
Billing scraper

Outbound, Private Le billing scraper collecte les données d’utilisation depuis ClickHouse et les envoie vers un bucket détenu par ClickHouse Cloud — S3 sur AWS, Cloud Storage sur GCP, Blob Storage sur Azure. Il s’exécute comme sidecar aux côtés du conteneur du ClickHouse server et scrape périodiquement les métriques de CPU et de mémoire des system tables de ClickHouse. Les enregistrements sont indexés par un identifiant de service opaque et un nom de pod. Les requests intra-Region empruntent le chemin privé vers les storage APIs du provider répertoriées dans Équivalents chez les providers : ce trafic ne transite donc pas par l’Internet public sur AWS ou GCP.
Ce stream ne transporte que des métriques système et des metadata opérationnelles. Il ne contient aucune row de table, aucune column value, ni aucun query text brut.

​
Alerts

Outbound, Public AlertManager est configuré pour envoyer des alerts à ClickHouse Cloud lorsque votre ClickHouse cluster n’est pas sain. Les payloads d’alert BYOC sont délibérément réduits à un nom d’alert et à un identifiant de service. L’ensemble complet des données de monitoring reste dans votre propre account sur chaque cloud. Il faut distinguer ici deux choses, car leurs frontières diffèrent :
  • Exporté en continu. La telemetry réduite d’usage et de health décrite à la section Billing scraper, ainsi que ces payloads d’alert, constituent les seules données d’observability écrites dans les systèmes détenus par ClickHouse. Le remote-write Prometheus vers ClickHouse Cloud est disabled dans les builds BYOC.
  • Lu sur place. Les dashboards de monitoring de ClickHouse et, après escalation approuvée, ses ingénieurs interrogent le stack Prometheus in-cluster et vos logs via Tailscale — voir Tailscale Private Network. Le résultat de la requête parvient nécessairement à l’outillage côté ClickHouse pour être affiché, mais rien n’y est persisté et les données sous-jacentes ne quittent jamais votre account.
Les metrics reposent sur un stack Prometheus et Thanos s’exécutant dans votre cluster, avec une retention à long terme optionnelle dans un bucket de votre propre account ; si vous activez cette retention, les writes sortent de votre réseau BYOC vers la storage API du provider, mais les données restent dans votre account. Les logs sont actuellement écrits sur les volumes des nodes attachés à vos nodes ClickHouse ; lors d’une prochaine mise à jour, ils seront écrits dans LogHouse, un magasin de logs basé sur ClickHouse qui s’exécute lui aussi à l’intérieur de votre réseau BYOC.

​
État du service

Outbound, Public Le state exporter transmet les informations d’état du ClickHouse service et des Backups — des événements de statut opérationnel, et non le contenu des Backups — vers une queue appartenant à ClickHouse Cloud : SQS sur AWS, Pub/Sub sur GCP, Service Bus sur Azure. C’est ce qui permet à la ClickHouse Cloud console d’afficher le status d’un service exécuté dans votre account.

​
Trafic intra-réseau

Le trafic entre les composants internes au cluster — de ClickHouse vers ClickHouse Keeper, l’operator, l’Ingress vers les pods ClickHouse, les scrapes de monitoring — ne quitte jamais votre réseau BYOC. Chaque provider chiffre le trafic entre ses propres instances au niveau de la couche réseau : voir AWS, GCP et Azure. Par défaut, l’egress n’est pas restreint au niveau des Security Groups, des règles de firewall ni des network security groups ; les destinations réellement contactées sont celles indiquées dans Outbound connections. Un firewall d’egress optionnel, propre à chaque service, peut au contraire imposer une allowlist de destinations — contactez votre ClickHouse team si vous en avez besoin.

​
Audit de la frontière

Comme l’ensemble du plan de données s’exécute dans votre propre compte, les flux décrits sur cette page sont observables avec vos propres outils. Certaines sources sont actives par défaut, d’autres doivent être activées par vos soins :
  • Piste d’audit cloud (CloudTrail, Cloud Audit Logs ou le journal Activity d’Azure) : chaque assomption de rôle, chaque impersonation de service account ou connexion de service principal effectuée par l’automatisation ClickHouse, ainsi que chaque appel d’API cloud réalisé avec celle-ci.
  • Flow logs (VPC Flow Logs, VPC flow logs ou NSG flow logs) : les connexions ci-dessus qui traversent votre propre réseau — l’ingress client, chaque flux Outbound et le canal Tailscale. Activez-les vous-même si vous souhaitez les conserver. L’accès de management au serveur d’API Kubernetes fait exception : tant que le public endpoint est utilisé, celui-ci se termine au niveau de l’endpoint de plan de contrôle Managed de votre provider et non à l’intérieur de votre réseau ; il n’apparaît donc pas dans vos flow logs. Recherchez-le plutôt dans les audit logs Kubernetes et dans votre piste d’audit cloud ; il ne figure dans les flow logs qu’une fois le serveur d’API Kubernetes basculé sur un point de terminaison privé.
  • Audit logs Kubernetes : sur AWS, les logs du plan de contrôle EKS, y compris l’audit log, sont livrés à un groupe de logs CloudWatch dans votre compte ; sur GCP et Azure, contactez le Support pour confirmer ou activer le logging d’audit du plan de contrôle de votre cluster.
  • Logs d’accès au stockage d’objet sur vos buckets de données et de Backup, ainsi que sur le bucket de rétention Monitoring à long terme lorsque vous l’avez activé.
  • Votre propre system.query_log : chaque statement exécuté par l’automatisation ClickHouse ou par un ingénieur, avec l’identity associée.
Dernière modification le 28 septembre 2026