Skip to main content

​
Conexiones entre el plano de control de ClickHouse y su VPC de BYOC

El plano de control de ClickHouse Cloud mantiene varios tipos de conexiones para operar y dar soporte a su implementación de BYOC:

​
API de proveedores de nube frente a la API de Kubernetes

Es fácil confundir dos rutas de control distintas. Se diferencian por el origen del tráfico, el método de autenticación y la aplicabilidad de Tailscale: En resumen: solo el tráfico de la API de Kubernetes y el de resolución de problemas pueden usar Tailscale. Las llamadas de administración descritas anteriormente siempre se originan en la red de ClickHouse Cloud y terminan en los endpoints del proveedor; no es posible enrutarlas a través de Tailscale, ya que nunca entran en su red. Las API de los proveedores de nube también se invocan en el sentido contrario, desde controladores que se ejecutan dentro de su propio cluster: el controlador del balanceador de carga, el controlador CSI, el autoescalador, el controlador de DNS y cert-manager. Esas llamadas utilizan identidades internas del cluster y salen por su propia ruta de salida, por lo que aparecen en su registro de auditoría con una identidad y una dirección de origen distintas de las de las llamadas de administración. Consulte Conexiones salientes.

​
Límites de permisos según el origen de red

Si su organización restringe la asunción de roles de IAM o las llamadas a la API de Cloud según el origen de red (por ejemplo, mediante SCP de AWS o condiciones de confianza de roles que usan aws:SourceIp o aws:SourceVpc), esas condiciones bloquearán la automatización de ClickHouse: las llamadas se originan legítimamente en la red de ClickHouse Cloud, no en la suya. Exima de dichas condiciones a los roles creados por ClickHouse o póngase en contacto con ClickHouse para obtener los rangos actuales de IP de salida si debe usar una lista de permitidos según el origen. La siguiente sección describe cómo se utiliza la red privada de Tailscale para la resolución de problemas y el acceso opcional de administración.

​
Red privada de Tailscale

Tailscale proporciona una conexión de red privada de confianza cero entre los servicios de administración de ClickHouse Cloud y su implementación BYOC. Este canal seguro permite a los ingenieros de ClickHouse realizar tareas de resolución de problemas y operaciones de administración sin necesidad de acceso entrante desde la red pública ni de configuraciones de VPN complejas; los propios agentes realizan conexiones únicamente salientes y necesitan acceso saliente a internet para llegar al servicio de coordinación de Tailscale.

​
Descripción general

Tailscale crea un túnel de red privado y cifrado entre el plano de control de ClickHouse (en la VPC de ClickHouse) y tu plano de datos de BYOC (en tu VPC). Esta conexión se usa exclusivamente para:
  • Operaciones de administració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 del stack 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 en tu propia cuenta en la nube y nunca se transmiten a través de conexiones de Tailscale.

​
Cómo funciona Tailscale en BYOC

Para cada servicio o endpoint al que se deba acceder mediante Tailscale, ClickHouse BYOC despliega:
  1. 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 la API de Kubernetes)
  2. Contenedor del agente de Tailscale: Un contenedor del agente de Tailscale se ejecuta en su clúster de Kubernetes 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
  3. Pod de Nginx: Un pod 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 Kubernetes

​
Proceso de conexión de red

El establecimiento de la conexión de Tailscale sigue estos pasos:
  1. Conexión inicial:
    • Los agentes de Tailscale en ambos extremos (el entorno de los ingenieros de ClickHouse y su clúster de Kubernetes en BYOC) se conectan al servidor de coordinación de Tailscale
    • El agente del clúster registra el servicio de Kubernetes para que sea detectable
    • Los ingenieros de ClickHouse deben escalar internamente para obtener visibilidad del servicio
  2. 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
  3. 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

Conexiones solo salientes:
  • Los agentes de Tailscale en su clúster de Kubernetes 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

De forma predeterminada, el servicio de administración de ClickHouse accede a su clúster de Kubernetes BYOC a través del endpoint público del servidor de la API, que cada nube controla de forma distinta: en AWS mediante una lista de IP permitidas que contiene únicamente las direcciones del gateway NAT de ClickHouse, y en GCP y Azure mediante IAM de la nube. Consulte Exposición del servidor de la API de Kubernetes para conocer los detalles de cada nube. Configuración opcional del endpoint privado:
  • Puede configurar el servidor de la API de Kubernetes 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) o, en AWS, a través de VPC Lattice (consulte Kubernetes API Private Connection)
  • De forma predeterminada, el endpoint público se mantiene como mecanismo de respaldo para casos de investigación y soporte de emergencia; una vez verificado el acceso privado, puede deshabilitarse por completo en coordinación con ClickHouse

​
Flujo del tráfico de red

Flujo de conexión de Tailscale:
  1. Agente de Tailscale en su clúster de Kubernetes → servidor de coordinación de Tailscale (saliente)
  2. Agente de Tailscale en la máquina del ingeniero → servidor de coordinación de Tailscale (saliente)
  3. Se establece una conexión directa o retransmitida entre los agentes
  4. El tráfico cifrado fluye a través del túnel establecido
  5. El pod de Nginx en su clúster de Kubernetes 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 en su propia cuenta en la nube
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.

​
Límites de red

Esta sección presenta la vista de firewall de una implementación de BYOC: cada conexión que cruza el límite de su red de BYOC, en cualquier dirección. Se aplica a AWS, GCP y Azure; cuando el comportamiento difiere entre nubes, se indica la nube de forma explícita. Términos utilizados a lo largo del documento:
  • Entrante: tráfico que entra en su red de BYOC, ya sea una VPC en AWS, una red VPC en GCP o una VNet en Azure.
  • Saliente: tráfico que se origina en su red de BYOC y se envía a un destino externo.
  • Público: un endpoint accesible desde la red pública de internet.
  • Privado: un endpoint accesible únicamente a través de una ruta privada: emparejamiento de VPC/VNet, AWS PrivateLink, GCP Private Service Connect, Azure Private Link o Tailscale.

​
Equivalencias entre proveedores

El resto de esta página utiliza nombres neutrales respecto al proveedor de nube. Esta tabla los relaciona con cada proveedor: La salida hacia el public internet sale de su red BYOC a través de un conjunto reducido y fijo de direcciones NAT en todas las nubes, por lo que puede fijarlas en sus propios controles de salida. Solicite al ClickHouse team los valores vigentes para su despliegue. En AWS y GCP, el tráfico hacia las storage APIs propias del proveedor es la excepción: sigue la ruta privada indicada en la fila anterior y nunca llega al gateway NAT.

​
Conexiones entrantes

En estos balanceadores de carga a veces se ven dos puertos que no están orientados al cliente: el TCP 15021 atiende las comprobaciones de estado propias del proveedor contra el ingress gateway y no transporta tráfico de consultas, y la interfaz de MySQL (puerto 3306) no está expuesta actualmente en BYOC; consulte las FAQ. El certificado del ingress gateway lo emite cert-manager desde una autoridad de certificación ACME pública (Let’s Encrypt) mediante validación DNS-01, y se almacena como un Kubernetes secret dentro de su propio cluster. El tráfico entre el ingress gateway y los pods de ClickHouse permanece dentro de su red BYOC; consulte Tráfico intra-red. Cuál de los dos balanceadores de carga se habilita de forma predeterminada depende de su modelo de red. Con una VPC gestionada por ClickHouse, cada servicio obtiene el public load balancer, protegido por una lista de acceso por IP, y el private load balancer puede habilitarse junto a él. Con una VPC gestionada por el cliente, los valores predeterminados se invierten: solo se habilita el private load balancer y sus servicios no tienen ninguna superficie de ingreso público a menos que usted añada una. Consulte Conectarse a su servicio BYOC. Siempre que la ruta pública esté habilitada, recomendamos encarecidamente configurar un filtro de IP; además puede añadir una ruta privada —consulte Configuración de red privada— y después deshabilitar por completo el acceso público. Tenga en cuenta que el filtrado de IP se aplica en la capa del proxy de ingreso, por lo que los puertos del balanceador de carga pueden aparecer abiertos en un escaneo aunque las conexiones desde orígenes no listados se rechacen.
Más allá de los listeners anteriores no hay SSH, ni host bastión, ni credenciales administrativas permanentes. El tráfico de consultas nunca atraviesa infraestructura propiedad de ClickHouse en ninguna dirección: sus client se conectan directamente al ingreso dentro de su propia red.Se pueden habilitar puertos de protocolo adicionales en cada despliegue —el acceso native autenticado por certificado y Arrow Flight son los ejemplos actuales—, así que confirme con su equipo de ClickHouse el conjunto exacto de puertos de su despliegue antes de escribir reglas de cortafuegos a partir de esta tabla.

​
Exposición del servidor de la API de Kubernetes

La forma en que los servicios de administración de ClickHouse acceden al servidor de la API de Kubernetes, y qué restringe ese acceso, varía según la nube:
  • AWS (EKS): el public endpoint está restringido a los rangos CIDR de salida de ClickHouse mediante la lista de CIDR de acceso público del cluster. Puede cambiarse a acceso exclusivamente privado mediante Tailscale o VPC Lattice: consulte Kubernetes API Private Connection.
  • GCP (GKE): los nodes son siempre privados. Se accede al plano de control a través de su endpoint basado en DNS (*.gke.goog), autorizado mediante la permission de IAM container.clusters.connect sobre la service account suplantada y no mediante una lista de IP permitidas. La request termina en el frontend de Google y no dentro de su red VPC, pero sigue siendo una vía de acceso al plano de control de su cluster, así que conviene revisarla como acceso entrante. El public endpoint independiente basado en IP puede deshabilitarse, con lo que el endpoint basado en DNS queda como la única ruta al plano de control: consulte Kubernetes API Private Connection.
  • Azure (AKS): se accede al API server a través de su FQDN público y se autoriza mediante Microsoft Entra ID junto con Azure RBAC. Los rangos de IP autorizados del API server no se aplican de forma predeterminada; contacte con ClickHouse si su policy los exige. Como alternativa, el cluster puede crearse como un cluster privado accesible mediante Azure Private Link, con su FQDN público deshabilitado: consulte Kubernetes API Private Connection.
Solo el tráfico de la Kubernetes API y el de resolución de problemas puede trasladarse a una ruta privada. Las llamadas de administración a las API de su cloud provider se originan en la red de ClickHouse Cloud y no pueden enrutarse por ella: consulte API de los proveedores cloud frente a la Kubernetes API, donde también se abordan las API calls al proveedor que realizan los controllers dentro de su propio cluster.

​
Resolución de problemas

Inbound, Private Los ingenieros de ClickHouse Cloud acceden a su despliegue para tareas de resolución de problemas únicamente a través de Tailscale, nunca por la internet pública, en todas las nubes. El acceso es just-in-time y se basa en certificados: un ingeniero lo solicita mediante un workflow interno de aprobación, la plataforma genera una credencial de corta duración para cada ingeniero y esta expira automáticamente. No existe ninguna identidad administrativa compartida ni acceso permanente. Consulte ClickHouse data access para conocer la política completa, incluidas las tablas que los ingenieros pueden leer.

​
Conexiones salientes

​
Billing scraper

Saliente, Private El billing scraper recopila datos de uso de ClickHouse y los envía a un bucket propiedad de ClickHouse Cloud: S3 en AWS, Cloud Storage en GCP y Blob Storage en Azure. Se ejecuta como sidecar junto al contenedor del ClickHouse server y realiza periódicamente scrape de las métricas de CPU y memoria de las tablas del sistema de ClickHouse. Los registros se indexan con clave mediante un identificador opaco de servicio y el nombre del pod de Kubernetes. Las solicitudes dentro de la misma Region siguen la ruta privada hacia las storage API del provider indicadas en Equivalencias entre proveedores, por lo que este tráfico no atraviesa el public internet en AWS ni en GCP.
Este stream transporta únicamente métricas del sistema y metadata operativa. No contiene filas de tablas, ni valores de columnas, ni texto de consultas sin procesar.

​
Alertas

Saliente, Público AlertManager está configurado para enviar alertas a ClickHouse Cloud cuando tu cluster de ClickHouse no está en buen estado. Los payloads de las alertas de BYOC se reducen deliberadamente a un nombre de alerta y un identificador de servicio. El conjunto completo de datos de monitorización permanece en tu propia cuenta en todos los clouds. Conviene distinguir aquí dos cosas, porque tienen límites diferentes:
  • Exportado continuamente. La telemetría reducida de uso y estado descrita en Billing scraper, junto con estos payloads de alertas, son los únicos datos de observabilidad que se escriben en sistemas propiedad de ClickHouse. El remote-write de Prometheus hacia ClickHouse Cloud está deshabilitado en los builds de BYOC.
  • Leído en origen. Los dashboards de monitorización de ClickHouse y, previa escalation aprobada, sus ingenieros consultan el stack de Prometheus del cluster y tus logs a través de Tailscale — consulta Tailscale Private Network. Los query results necesariamente llegan a las herramientas del lado de ClickHouse para poder mostrarse, pero allí no se persiste nada y los datos subyacentes nunca salen de tu cuenta.
Las metrics se apoyan en un stack de Prometheus y Thanos que se ejecuta en tu cluster, con retención opcional a largo plazo en un bucket de tu propia cuenta; si habilitas esa retención, los writes salen de tu red BYOC hacia la storage API del provider, pero los datos permanecen dentro de tu cuenta. Actualmente los logs se escriben en los volumes asociados a tus nodes de ClickHouse; en una actualización futura se escribirán en LogHouse, un almacén de logs basado en ClickHouse que también se ejecuta dentro de tu red BYOC.

​
Estado del servicio

Saliente, Público El state exporter envía información sobre el estado del servicio de ClickHouse y de los backups —eventos de estado operativo, no el contenido de los backups— a una cola propiedad de ClickHouse Cloud: SQS en AWS, Pub/Sub en GCP y Service Bus en Azure. Esto es lo que permite que la consola de ClickHouse Cloud muestre el estado de un servicio que se ejecuta en su cuenta.

​
Tráfico intrarred

El tráfico entre componentes dentro del cluster —de ClickHouse a ClickHouse Keeper, el operator, del ingreso a los pods de ClickHouse, los scrape de monitoreo— nunca sale de su red BYOC. Cada provider cifra el tráfico entre sus propias instancias en la capa de red: consulte AWS, GCP y Azure. De forma predeterminada, la salida no está restringida en la capa del security group, las reglas de firewall ni el network security group; los destinos que realmente se contactan son los indicados en Conexiones salientes. Opcionalmente, un firewall de salida por servicio puede aplicar en su lugar una allowlist de destinos: comuníquese con su equipo de ClickHouse si lo necesita.

​
Auditar el perímetro

Dado que todo el plano de datos se ejecuta en su propia cuenta, los flujos descritos en esta página pueden observarse con sus propias herramientas. Algunas fuentes están activadas de forma predeterminada; otras debe habilitarlas usted mismo:
  • Rastro de auditoría de la nube (CloudTrail, Cloud Audit Logs o el Activity log de Azure): cada role assumption, cada impersonation de una service account o cada inicio de sesión de una entidad de servicio por parte de la automatización de ClickHouse, así como cada llamada a la API de la nube realizada con ella.
  • Flow logs (VPC Flow Logs, VPC flow logs o NSG flow logs): las connections anteriores que atraviesan su propia red, es decir, el ingreso de clientes, cada flujo saliente y el canal de Tailscale. Habilítelos usted mismo si desea conservarlos. El acceso de management al Kubernetes API server es la excepción: mientras se utilice el public endpoint, este termina en el endpoint del plano de control administrado de su provider y no dentro de su red, por lo que no aparece en sus flow logs. Búsquelo, en cambio, en los audit logs de Kubernetes y en el rastro de auditoría de su nube; solo aparecerá en los flow logs cuando el API server se cambie a un Private Endpoint.
  • Audit logs de Kubernetes: en AWS, los logs del plano de control de EKS, incluido el audit log, se envían a un grupo de logs de CloudWatch en su cuenta; en GCP y Azure, contacte con soporte para confirmar o habilitar el logging de auditoría del plano de control de su cluster.
  • Logs de acceso al almacenamiento de objetos de sus buckets de datos y de backup, y del bucket de retención de monitoring a largo plazo donde lo tenga habilitado.
  • Su propio system.query_log: cada statement ejecutado por la automatización de ClickHouse o por un ingeniero, con la identity asociada.
Última modificación el 28 de septiembre de 2026