Connexions entre le plan de contrôle ClickHouse et votre VPC BYOC
API des fournisseurs de Cloud et API Kubernetes
En bref : seuls l’API Kubernetes et le trafic de dépannage peuvent utiliser Tailscale. Les appels d’API des fournisseurs de Cloud 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.
Limites d’autorisation selon l’origine réseau
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
Vue d’ensemble
- 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.
Fonctionnement de Tailscale dans BYOC
-
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.compour le serveur d’API Kubernetes) -
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
-
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
-
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
-
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
-
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é
- 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
- 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
Accès aux services de gestion
- 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 (restreint aux adresses IP NAT de ClickHouse) 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
- agent Tailscale dans votre cluster Kubernetes → serveur de coordination Tailscale (sortant)
- agent Tailscale sur la machine de l’ingénieur → serveur de coordination Tailscale (sortant)
- Connexion directe ou relayée établie entre les agents
- Le trafic chiffré transite par le tunnel établi
- Le pod Nginx dans EKS assure la terminaison TLS et achemine le trafic vers les services internes
- 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 VPC
Périmètres réseau
- Entrant : trafic qui entre dans le VPC BYOC du client.
- Sortant : trafic provenant du VPC BYOC du client et envoyé vers une destination externe.
- Public : point de terminaison réseau accessible depuis l’internet public.
- Privé : point de terminaison réseau accessible uniquement via des connexions privées, comme le VPC peering, VPC Private Link ou Tailscale.