Skip to main content

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

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

​
API облачного провайдера и API Kubernetes

Два разных пути управления легко спутать. Они различаются источником трафика, способом аутентификации и возможностью использования Tailscale: Иными словами, только трафик API Kubernetes и трафик для устранения неполадок могут использовать Tailscale. Описанные выше управляющие вызовы всегда исходят из сети ClickHouse Cloud и завершаются на конечных точках провайдера — маршрутизировать их через Tailscale невозможно, поскольку они вообще не попадают в вашу сеть. API облачного провайдера вызываются и с другой стороны — контроллерами, работающими внутри вашего собственного кластера: контроллером балансировщика нагрузки, драйвером CSI, автоскейлером, контроллером DNS и cert-manager. Эти вызовы используют внутрикластерные идентичности и уходят через ваш собственный путь исходящего трафика, поэтому в журнале аудита они отображаются с другой идентичностью и другим адресом источника, нежели управляющие вызовы. См. Исходящие подключения.

​
Ограничения разрешений по источнику сетевого трафика

Если в вашей организации ограничено принятие роли IAM или вызовы Cloud API в зависимости от источника сетевого трафика (например, с помощью AWS SCP или условий доверия роли с aws:SourceIp или aws:SourceVpc), эти условия заблокируют автоматизацию ClickHouse: вызовы правомерно исходят из сети ClickHouse Cloud, а не из вашей. Исключите роли, созданные ClickHouse, из таких условий или обратитесь в ClickHouse за актуальными диапазонами исходящих IP-адресов, если необходимо разрешать доступ по источнику. В следующем разделе описано использование частной сети Tailscale для устранения неполадок и дополнительного административного доступа.

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

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

​
Обзор

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

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

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

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

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

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

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

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

По умолчанию сервисы управления ClickHouse обращаются к вашему Kubernetes-кластеру BYOC через публичную конечную точку API-сервера, доступ к которой в каждом облаке ограничивается по-разному: в AWS — списком разрешённых IP, содержащим только адреса шлюза NAT ClickHouse, а в GCP и Azure — облачным IAM. Подробности по каждому облаку см. в разделе Доступность API-сервера Kubernetes. Необязательная настройка частной конечной точки:
  • Вы можете настроить API-сервер Kubernetes так, чтобы он использовал только частную конечную точку
  • В этом случае сервисы управления получают доступ к API-серверу через Tailscale (аналогично доступу для устранения неполадок у пользователей) или, в AWS, через VPC Lattice (см. Частное подключение к API Kubernetes)
  • По умолчанию публичная конечная точка сохраняется как резервный механизм для экстренной диагностики и задач поддержки; после проверки частного доступа её можно полностью отключить по согласованию с ClickHouse

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

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

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

Этот раздел описывает BYOC-развертывание с точки зрения firewall: каждое соединение, пересекающее границу вашей сети BYOC в любом направлении. Он применим к AWS, GCP и Azure; там, где поведение облаков различается, облако указано явно. Используемые далее термины:
  • входящий: трафик, входящий в вашу сеть BYOC — VPC в AWS, сеть VPC в GCP или VNet в Azure.
  • Outbound: трафик, исходящий из вашей сети BYOC и направляемый во внешний пункт назначения.
  • Public: конечная точка, доступная из публичного интернета.
  • Private: конечная точка, доступная только по частному маршруту — пиринг VPC/VNet, AWS PrivateLink, GCP Private Service Connect, Azure Private Link или Tailscale.

​
Соответствия у провайдеров

Далее на этой странице используются облачно-нейтральные названия. В таблице показано, чему они соответствуют у каждого провайдера: Исходящий трафик в публичный интернет покидает вашу сеть BYOC через небольшой фиксированный набор NAT-адресов — и так в любом облаке, поэтому вы можете зафиксировать их в собственных правилах контроля исходящего трафика. Актуальные значения для вашего развертывания запросите у команды ClickHouse. В AWS и GCP исключение составляет трафик к собственным storage API провайдера: он идет по частному пути из строки выше и до NAT gateway не доходит.

​
Входящие подключения

На этих балансировщиках нагрузки иногда видны еще два порта, но они не предназначены для клиентов: TCP 15021 обслуживает собственные проверки работоспособности провайдера для входящего шлюза и не передает трафик запросов, а интерфейс MySQL (порт 3306) в BYOC в настоящее время не открыт — см. FAQ. Сертификат входящего шлюза выпускается cert-manager публичным центром сертификации ACME (Let’s Encrypt) с использованием проверки DNS-01 и хранится как Kubernetes secret внутри вашего собственного кластера. Трафик между входящим шлюзом и подами ClickHouse не покидает вашу сеть BYOC — см. Внутрисетевой трафик. Какой из двух балансировщиков нагрузки включен по умолчанию, зависит от вашей сетевой модели. При VPC, управляемом ClickHouse, каждый сервис получает публичный балансировщик нагрузки, защищенный IP access list, а частный балансировщик нагрузки можно включить дополнительно. При управляемом клиентом VPC настройки по умолчанию противоположны: включен только частный балансировщик нагрузки, и у ваших сервисов нет публичной точки входа, пока вы ее не добавите. См. Подключение к сервису BYOC. Везде, где включен публичный путь, мы настоятельно рекомендуем настроить IP-фильтр; вы также можете добавить частный путь — см. Настройка частной сети — и затем полностью отключить публичный доступ. Обратите внимание, что IP-фильтрация применяется на уровне входящего прокси, поэтому при сканировании порты балансировщика нагрузки могут выглядеть открытыми, тогда как подключения из неуказанных источников будут отклонены.
Помимо перечисленных выше listener’ов, нет ни SSH, ни bastion-хоста, ни постоянных административных учетных данных. Трафик запросов ни в одном направлении не проходит через инфраструктуру, принадлежащую ClickHouse: ваши клиенты подключаются напрямую к входящему шлюзу внутри вашей собственной сети.Для отдельных развертываний могут быть включены дополнительные порты протоколов — текущие примеры: native-доступ с аутентификацией по сертификату и Arrow Flight, — поэтому уточните точный набор портов для вашего развертывания у вашей команды ClickHouse, прежде чем составлять правила межсетевого экрана на основе этой таблицы.

​
Доступность API-сервера Kubernetes

То, как сервисы управления ClickHouse обращаются к API-серверу Kubernetes и что ограничивает этот доступ, зависит от облака:
  • AWS (EKS): публичная конечная точка ограничена CIDR-диапазонами исходящего трафика ClickHouse через список публичных CIDR кластера. Её можно перевести в режим доступа только по приватной сети с помощью Tailscale или VPC Lattice — см. Частное подключение к API Kubernetes.
  • GCP (GKE): узлы всегда приватные. Обращение к плоскости управления выполняется через его DNS-конечную точку (*.gke.goog), а авторизация — по IAM-разрешению container.clusters.connect для сервисного аккаунта, от имени которого выполняется имперсонация, а не по списку разрешённых IP. Запрос завершается на фронтенде Google, а не внутри вашей VPC-сети, но это всё равно путь доступа к плоскости управления вашего кластера, поэтому рассматривайте его как входящий доступ. Отдельную публичную конечную точку на основе IP можно отключить, и тогда DNS-конечная точка останется единственным путём к плоскости управления — см. Частное подключение к API Kubernetes.
  • Azure (AKS): обращение к API-серверу выполняется по его публичному FQDN, а авторизация — через Microsoft Entra ID совместно с Azure RBAC. Авторизованные диапазоны IP для API-сервера по умолчанию не применяются; свяжитесь с ClickHouse, если этого требует ваша политика. Кроме того, кластер можно создать как приватный, с доступом через Azure Private Link и отключённым публичным FQDN — см. Частное подключение к API Kubernetes.
На приватный путь можно перевести только трафик Kubernetes API и диагностики. Управляющие вызовы к API вашего облачного провайдера исходят из сети ClickHouse Cloud и не могут быть направлены через него — см. API облачных провайдеров и Kubernetes API, где также рассматриваются вызовы API провайдера, выполняемые контроллерами внутри вашего собственного кластера.

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

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

​
Исходящие подключения

​
Сборщик данных для биллинга

Outbound, Private Сборщик данных для биллинга собирает сведения об использовании из ClickHouse и отправляет их в бакет, принадлежащий ClickHouse Cloud — S3 в AWS, Cloud Storage в GCP, Blob Storage в Azure. Он работает как sidecar рядом с контейнером ClickHouse server и периодически считывает метрики CPU и памяти из системных таблиц ClickHouse. Ключом для записей служат непрозрачный идентификатор сервиса и имя пода. Запросы в пределах одного региона идут по частному маршруту к storage API провайдера, перечисленным в разделе Соответствия провайдеров, поэтому в AWS и GCP такой трафик не выходит в публичный интернет.
Этот поток передаёт только системные метрики и эксплуатационные метаданные. Он не содержит ни строк таблиц, ни значений столбцов, ни исходного текста запросов.

​
Оповещения

Outbound, Public AlertManager настроен на отправку оповещений в ClickHouse Cloud, когда ваш ClickHouse cluster работает некорректно. Полезная нагрузка оповещений в BYOC намеренно сокращена до имени оповещения и идентификатора сервиса. Полный набор данных мониторинга остаётся в вашем собственном аккаунте в любом облаке. Здесь важно различать два случая, так как границы у них разные:
  • Непрерывный экспорт. Сокращённая телеметрия использования и состояния, описанная в разделе сборщик данных для биллинга, а также эти полезные нагрузки оповещений — единственные данные обсервабилити, которые записываются в системы, принадлежащие ClickHouse. Prometheus remote-write в ClickHouse Cloud в сборках BYOC отключён.
  • Чтение на месте. Панели мониторинга ClickHouse и — при одобренной эскалации — инженеры ClickHouse обращаются с запросами к Prometheus stack внутри кластера и к вашим журналам через Tailscale — см. Tailscale Private Network. Результаты запросов неизбежно попадают в инструменты на стороне ClickHouse, чтобы их можно было отобразить, но там ничего не сохраняется, а сами данные никогда не покидают ваш аккаунт.
Для метрик используется стек Prometheus и Thanos, работающий в вашем кластере, с опциональным долгосрочным хранением в бакете в вашем собственном аккаунте; если вы включите такое хранение, записи будут покидать вашу сеть BYOC и направляться в storage API провайдера, но данные останутся в пределах вашего аккаунта. Журналы сейчас записываются на тома узлов, подключённые к вашим узлам ClickHouse; в одном из будущих обновлений они будут записываться в LogHouse — хранилище журналов на базе ClickHouse, которое также работает внутри вашей сети BYOC.

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

Исходящий, публичный State exporter отправляет информацию о состоянии сервиса ClickHouse и резервных копий — события операционного статуса, а не само содержимое резервных копий — в очередь, принадлежащую ClickHouse Cloud: SQS в AWS, Pub/Sub в GCP, Service Bus в Azure. Именно благодаря этому консоль ClickHouse Cloud отображает статус сервиса, работающего в вашем аккаунте.

​
Внутрисетевой трафик

Трафик между компонентами внутри кластера — от ClickHouse к ClickHouse Keeper, трафик оператора, от входного шлюза к подам ClickHouse, сбор метрик мониторинга — никогда не покидает вашу сеть BYOC. Каждый провайдер шифрует трафик между своими инстансами на сетевом уровне: см. AWS, GCP и Azure. Исходящий трафик по умолчанию не ограничивается на уровне security group, правил firewall и network security group; фактически используются только те пункты назначения, которые перечислены в разделе Исходящие подключения. При необходимости для каждого сервиса можно включить отдельный egress-firewall, который будет применять список разрешённых пунктов назначения — если это нужно, обратитесь к вашей команде ClickHouse.

​
Аудит границы

Поскольку вся плоскость данных работает в вашем собственном аккаунте, описанные на этой странице потоки можно отслеживать вашими собственными инструментами. Часть источников включена по умолчанию, остальные вы включаете самостоятельно:
  • Облачный журнал аудита (CloudTrail, Cloud Audit Logs или Azure Activity log): каждое принятие роли (role assumption), олицетворение сервисного аккаунта или вход сервисного субъекта со стороны автоматизации ClickHouse, а также каждый вызов облачного API, выполненный с их использованием.
  • Журналы потоков (VPC Flow Logs, VPC flow logs или NSG flow logs): описанные выше соединения, проходящие через вашу собственную сеть, — входящий трафик клиентов, все исходящие потоки и канал Tailscale. Включите их самостоятельно, если хотите, чтобы они сохранялись. Исключение — управляющий доступ к API-серверу Kubernetes: пока используется публичная конечная точка, соединение завершается на управляемой конечной точке плоскости управления вашего провайдера, а не внутри вашей сети, поэтому в журналах потоков оно не отображается. Ищите его в журналах аудита Kubernetes и в облачном журнале аудита; в журналах потоков оно появится только после переключения API-сервера на частную конечную точку.
  • Журналы аудита Kubernetes: в AWS журналы плоскости управления EKS, включая журнал аудита, доставляются в группу журналов CloudWatch в вашем аккаунте; в GCP и Azure обратитесь в службу поддержки, чтобы подтвердить или включить аудит плоскости управления для вашего кластера.
  • Журналы доступа к объектному хранилищу для ваших бакетов с данными и резервными копиями, а также для бакета долгосрочного хранения данных мониторинга, если он у вас включен.
  • Ваш собственный system.query_log: каждый оператор, выполненный автоматизацией ClickHouse или инженером, с привязанной identity.
Последнее изменение 28 сентября 2026 г.