Перейти к основному содержанию

​
Соединения между плоскостью управления ClickHouse и вашей VPC BYOC

Плоскость управления ClickHouse Cloud поддерживает несколько типов подключений, необходимых для работы и сопровождения вашего развертывания BYOC: В следующем разделе описано, как частная сеть Tailscale используется для устранения неполадок и, при необходимости, для доступа к управлению.

​
Частная сеть Tailscale

Tailscale обеспечивает подключение к частной сети с нулевым доверием между сервисом управления ClickHouse Cloud и вашим развертыванием BYOC. Этот защищенный канал позволяет инженерам ClickHouse выполнять диагностику и операции управления без необходимости предоставлять публичный доступ в интернет или настраивать сложные VPN-конфигурации.

​
Обзор

Tailscale создает зашифрованный частный сетевой туннель между плоскостью управления ClickHouse (в VPC ClickHouse) и вашей плоскостью данных BYOC (в вашей VPC). Это соединение используется исключительно для:
  • Операций управления: сервисы управления ClickHouse координируют работу с вашей инфраструктурой BYOC
  • Доступа для устранения неполадок: инженеры ClickHouse получают доступ к API-серверам Kubernetes и системным таблицам ClickHouse для диагностики
  • Доступа к метрикам: централизованные панели мониторинга ClickHouse получают метрики из стека Prometheus, развернутого в вашей VPC BYOC, обеспечивая инженерам ClickHouse обсервабилити этой среды.
Tailscale используется только для операций управления и устранения неполадок. Он никогда не используется для передачи трафика запросов или доступа к данным клиентов. Все данные клиентов остаются в вашей VPC и никогда не передаются через Tailscale.

​
Как работает Tailscale в BYOC

Для каждого сервиса или конечной точки, к которым нужен доступ через Tailscale, ClickHouse BYOC развертывает:
  1. Регистрация адреса tailnet: Каждая конечная точка регистрирует уникальный адрес tailnet (например, k8s.xxxx.us-east-1.aws.byoc.clickhouse-prd.com для API-сервера Kubernetes)
  2. Контейнер агента Tailscale: В вашем кластере EKS запускается контейнер агента Tailscale, который отвечает за:
    • Подключение к серверу координации Tailscale
    • Регистрацию сервисов, чтобы их можно было обнаруживать
    • Координацию настройки сети с подами Nginx
  3. Под Nginx: Под Nginx, который:
    • Терминирует TLS-трафик из Tailscale
    • Маршрутизирует трафик на соответствующие IP-адреса внутри вашего кластера EKS

​
Процесс сетевого соединения

Установление соединения в Tailscale включает следующие этапы:
  1. Начальное подключение:
    • Агенты Tailscale на обеих сторонах (в среде инженера ClickHouse и в вашем кластере BYOC EKS) подключаются к серверу координации Tailscale
    • Агент кластера EKS регистрирует сервис Kubernetes, чтобы он стал доступен для обнаружения
    • Инженеры ClickHouse должны пройти внутреннюю эскалацию, чтобы получить доступ к сервису
  2. Режим подключения:
    • Прямой режим: агенты пытаются установить прямое соединение через туннель с обходом NAT
    • Релейный режим: если установить прямое соединение не удается, обмен данными переключается в релейный режим через сервер Tailscale DERP (Distributed Encrypted Relay Protocol)
  3. Шифрование:
    • Весь обмен данными шифруется по схеме end-to-end
    • Каждый агент Tailscale генерирует собственную пару открытого и закрытого ключей (аналогично PKI)
    • Трафик остается зашифрованным независимо от того, используется прямой или релейный режим

​
Функции безопасности

Только исходящие соединения:
  • Агенты Tailscale в вашем кластере EKS инициируют исходящие соединения с серверами координации и ретрансляции Tailscale
  • Входящие соединения не требуются — правила Security Group не должны разрешать входящий трафик к агентам Tailscale
  • Это снижает поверхность атаки и упрощает настройку сетевой безопасности
Управление доступом:
  • Прежде чем Tailscale сможет направить их к конечной точке клиента, инженеры должны запросить доступ через внутренний процесс согласования
  • Доступ ограничен по времени и автоматически истекает
  • Все обращения проходят аудит и записываются в журнал
Полную политику доступа к данным — что могут видеть инженеры, аутентификацию по сертификатам и аудит на стороне клиента — см. в разделе доступ ClickHouse к данным.

​
Доступ сервисов управления

По умолчанию сервисы управления ClickHouse получают доступ к вашему Kubernetes-кластеру BYOC через публичный IP-адрес API-сервера EKS, к которому разрешён доступ только с IP-адресов шлюза NAT ClickHouse. Необязательная настройка частной конечной точки:
  • Вы можете настроить API-сервер EKS так, чтобы он использовал только частную конечную точку
  • В этом случае сервисы управления получают доступ к API-серверу через Tailscale (аналогично доступу для устранения неполадок у пользователей)
  • Публичный доступ сохраняется как резервный механизм для экстренной диагностики и задач поддержки

​
Поток сетевого трафика

Схема соединения Tailscale:
  1. Агент Tailscale в кластере EKS → сервер координации Tailscale (исходящее соединение)
  2. Агент Tailscale на машине инженера → сервер координации Tailscale (исходящее соединение)
  3. Между агентами устанавливается прямое соединение или соединение через ретранслятор
  4. Зашифрованный трафик проходит через установленный туннель
  5. Под Nginx в EKS завершает TLS и маршрутизирует трафик к внутренним сервисам
Передача данных клиентов отсутствует:
  • Соединения Tailscale используются только для управления и устранения неполадок
  • Трафик запросов и данные клиентов никогда не проходят через Tailscale
  • Все данные клиентов остаются в пределах вашего VPC
Более подробную техническую информацию о том, как Tailscale реализован в BYOC, см. в статье в блоге Building ClickHouse BYOC on AWS. О том, какие данные могут читать инженеры ClickHouse после подключения и как ClickHouse аудирует этот доступ, см. в разделе доступ ClickHouse к данным.

​
Сетевые границы

В этом разделе рассматриваются различные типы сетевого трафика в VPC BYOC клиента и из неё:
  • Входящий: трафик, поступающий в VPC BYOC клиента.
  • Исходящий: трафик, исходящий из VPC BYOC клиента и направляемый во внешний пункт назначения.
  • Публичный: сетевая конечная точка, доступная из публичного интернета.
  • Приватный: сетевая конечная точка, доступная только через приватные подключения, такие как пиринг VPC, VPC Private Link или Tailscale.
Входной шлюз Istio развёрнут за AWS NLB для приёма трафика от клиента ClickHouse. Входящий, публичный или приватный Входной шлюз Istio завершает TLS. Сертификат, выпущенный CertManager с помощью Let’s Encrypt, хранится как secret внутри кластера EKS. Трафик между Istio и ClickHouse шифруется средствами AWS, поскольку они находятся в одной VPC. По умолчанию входной шлюз общедоступен с фильтрацией по списку разрешённых IP-адресов. Клиенты могут настроить пиринг VPC, чтобы сделать его приватным и отключить публичные подключения. Мы настоятельно рекомендуем настроить IP-фильтр, чтобы ограничить доступ.

​
Доступ для устранения неполадок

Входящий, приватный Инженерам ClickHouse Cloud требуется доступ для устранения неполадок через Tailscale. Для развертываний BYOC им предоставляется аутентификация по сертификатам по модели just-in-time. Полную политику доступа см. в разделе доступ ClickHouse к данным.

​
Скрапер биллинга

Исходящий, приватный Скрапер биллинга собирает данные о биллинге из ClickHouse и отправляет их в S3 бакет, принадлежащий ClickHouse Cloud. Он работает как sidecar рядом с контейнером ClickHouse server, периодически собирая метрики CPU и памяти. Запросы в том же регионе маршрутизируются через сервисные конечные точки шлюза VPC.

​
Оповещения

Исходящий, публичный AlertManager настроен на отправку оповещений в ClickHouse Cloud, если кластер ClickHouse клиента работает некорректно. Метрики и журналы хранятся внутри BYOC VPC клиента. В настоящее время журналы хранятся локально в EBS. В одном из следующих обновлений они будут храниться в LogHouse, сервисе ClickHouse внутри BYOC VPC. Для метрик используется стек Prometheus и Thanos, размещенный локально в BYOC VPC клиента.

​
Состояние сервиса

Исходящий, публичный State Exporter отправляет сведения о состоянии сервиса ClickHouse в SQS, принадлежащую ClickHouse Cloud.
Последнее изменение 1 июля 2026 г.