Conexiones entre el plano de control de ClickHouse y su VPC de BYOC
| Propósito | Tipo de conexión | Notas |
|---|
| Operaciones diarias — servidor de API de Kubernetes | Pública con filtrado de IP (predeterminado) o Tailscale | Los servicios de administración se comunican con el servidor de API de EKS a través de la red pública, con acceso restringido mediante listas de IP permitidas. Después de la implementación inicial, opcionalmente puede cambiar esto a Tailscale para disponer de acceso privado. |
| Operaciones diarias — API de AWS | VPC de ClickHouse → AWS | Los servicios de administración invocan las API de AWS (por ejemplo, EKS, EC2) desde la propia VPC de ClickHouse Cloud hacia AWS. Esto no involucra ni su VPC ni Tailscale. |
| Resolución de problemas — servicio de ClickHouse | Tailscale | Los ingenieros de ClickHouse acceden al servicio de ClickHouse (por ejemplo, a las tablas del sistema) para realizar diagnósticos mediante Tailscale. |
| Resolución de problemas — servidor de API de Kubernetes | Tailscale | Los ingenieros de ClickHouse acceden al servidor de API de EKS para diagnosticar el clúster mediante Tailscale. |
- Operaciones de gestión: servicios de gestión de ClickHouse que se coordinan con tu infraestructura de BYOC
- Acceso para resolución de problemas: ingenieros de ClickHouse que acceden a los servidores de la API de Kubernetes y a las tablas del sistema de ClickHouse para realizar diagnósticos
- Acceso a métricas: los paneles centralizados de monitoreo de ClickHouse acceden a las métricas de la pila de Prometheus implementada en tu VPC de BYOC, lo que proporciona a los ingenieros de ClickHouse observabilidad sobre el entorno.
Tailscale se usa solo para operaciones de gestión y resolución de problemas. Nunca se usa para tráfico de consultas ni para acceder a datos de clientes. Todos los datos de los clientes permanecen dentro de tu VPC y nunca se transmiten a través de conexiones de Tailscale.
Cómo funciona Tailscale en BYOC
-
Registro de direcciones tailnet: Cada endpoint registra una dirección tailnet única (p. ej.,
k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com para el servidor de API de Kubernetes)
-
Contenedor del agente de Tailscale: Un contenedor del agente de Tailscale se ejecuta en su clúster de EKS y se encarga de:
- Conectarse al servidor de coordinación de Tailscale
- Registrar servicios para que puedan detectarse
- Coordinar la configuración de red con los pods de Nginx
-
Pod de Kubernetes de Nginx: Un pod de Kubernetes de Nginx que:
- Termina el tráfico TLS procedente de Tailscale
- Enruta el tráfico a las IP adecuadas dentro de su clúster de EKS
Proceso de conexión de red
-
Conexión inicial:
- Los agentes de Tailscale en ambos extremos (el entorno de los ingenieros de ClickHouse y su clúster de EKS en BYOC) se conectan al servidor de coordinación de Tailscale
- El agente del clúster de EKS registra el servicio de Kubernetes para que sea detectable
- Los ingenieros de ClickHouse deben escalar internamente para obtener visibilidad del servicio
-
Modo de conexión:
- Modo directo: Los agentes intentan establecer una conexión directa mediante un túnel de NAT traversal
- Modo de retransmisión: Si el modo directo falla, la comunicación pasa al modo de retransmisión a través de un servidor DERP (Distributed Encrypted Relay Protocol) de Tailscale
-
Cifrado:
- Toda la comunicación está cifrada de extremo a extremo
- Cada agente de Tailscale genera su propio par de claves pública y privada (similar a la PKI)
- El tráfico permanece cifrado independientemente de si utiliza el modo directo o el de retransmisión
Características de seguridad
- Los agentes de Tailscale en su clúster de EKS inician conexiones salientes a los servidores de coordinación/retransmisión de Tailscale
- No se requieren conexiones entrantes — ninguna regla de grupo de seguridad necesita permitir tráfico entrante hacia los agentes de Tailscale
- Esto reduce la superficie de ataque y simplifica la configuración de seguridad de la red
Control de acceso:
- Los ingenieros deben solicitar acceso a través de un flujo interno de aprobación antes de que Tailscale pueda enrutarles a un endpoint del cliente
- El acceso está limitado en el tiempo y vence automáticamente
- Todo acceso se audita y queda registrado
Para consultar la política completa de acceso a los datos — qué pueden ver los ingenieros, la autenticación basada en certificados y la auditoría del lado del cliente — consulte Acceso a los datos de ClickHouse.
Acceso a los servicios de gestión
- Puede configurar el servidor de la API de EKS para que utilice únicamente un endpoint privado
- En este caso, el servicio de administración accede al servidor de la API a través de Tailscale (de forma similar al acceso humano para la resolución de problemas)
- El acceso público se mantiene como mecanismo de respaldo para casos de investigación y soporte de emergencia
Flujo de conexión de Tailscale:
- Agente de Tailscale en el cluster de EKS → servidor de coordinación de Tailscale (saliente)
- Agente de Tailscale en la máquina del ingeniero → servidor de coordinación de Tailscale (saliente)
- Se establece una conexión directa o retransmitida entre los agentes
- El tráfico cifrado fluye a través del túnel establecido
- El pod de Nginx en EKS termina TLS y enruta el tráfico a los servicios internos
No se transmiten datos de clientes:
- Las conexiones de Tailscale se usan solo para administración y resolución de problemas
- El tráfico de consultas y los datos de los clientes nunca fluyen a través de Tailscale
- Todos los datos de los clientes permanecen dentro de su VPC
Para obtener más detalles técnicos sobre cómo se implementa Tailscale en BYOC, consulte el artículo del blog Building ClickHouse BYOC on AWS. Para saber qué pueden leer los ingenieros de ClickHouse una vez conectados y cómo ClickHouse audita ese acceso, consulte acceso a los datos de ClickHouse.
Esta sección describe los distintos tipos de tráfico de red hacia y desde la VPC BYOC del cliente:
- Inbound: Tráfico que entra en la VPC BYOC del cliente.
- Outbound: Tráfico que se origina en la VPC BYOC del cliente y se envía a un destino externo.
- Public: Un endpoint de red accesible desde Internet pública.
- Private: Un endpoint de red accesible solo mediante conexiones privadas, como peering de VPC, VPC Private Link o Tailscale.
El ingreso de Istio se implementa detrás de un AWS NLB para aceptar tráfico de clientes de ClickHouse.
Entrante, público o privado
El gateway de ingreso de Istio realiza la terminación TLS. El certificado, aprovisionado por CertManager con Let’s Encrypt, se almacena como un secret dentro del clúster de EKS. El tráfico entre Istio y ClickHouse está cifrado por AWS, ya que residen en la misma VPC.
De forma predeterminada, el ingreso es accesible públicamente con filtrado mediante una lista de IP permitidas. Los clientes pueden configurar peering de VPC para hacerlo privado y deshabilitar las conexiones públicas. Recomendamos encarecidamente configurar un filtro de IP para restringir el acceso.
Acceso para resolución de problemas
