Сетевая безопасность BYOC

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

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

Purpose	Connection type	Notes
Ежедневные операции — сервер API Kubernetes	Публичное с фильтрацией по IP (по умолчанию) или Tailscale	Службы управления взаимодействуют с сервером API EKS через публичную сеть, доступ к которой ограничен списками разрешённых IP-адресов. После первоначального развертывания вы при необходимости можете переключить это соединение на Tailscale для приватного доступа.
Ежедневные операции — AWS APIs	ClickHouse VPC → AWS	Службы управления вызывают AWS APIs (например, EKS, EC2) из собственного VPC ClickHouse Cloud в AWS. Это не затрагивает ваш VPC и не использует Tailscale.
Устранение неполадок — ClickHouse service	Tailscale	Инженеры ClickHouse получают доступ к службе ClickHouse (например, к системным таблицам) для диагностики через Tailscale.
Устранение неполадок — сервер API Kubernetes	Tailscale	Инженеры ClickHouse получают доступ к серверу API EKS для диагностики кластера через Tailscale.

В следующем разделе описано, как приватная сеть Tailscale используется для устранения неполадок и дополнительного (необязательного) управляющего доступа.

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

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

Обзор

Tailscale создает зашифрованный туннель частной сети между управляющей плоскостью ClickHouse (в VPC ClickHouse) и вашей плоскостью данных BYOC (в вашей VPC). Это соединение используется исключительно для:

• Операций управления: сервисы управления ClickHouse, координирующие работу с вашей инфраструктурой BYOC
• Доступа для устранения неполадок: инженеры ClickHouse получают доступ к серверам Kubernetes API и системным таблицам 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 для сервера Kubernetes API)

2. Контейнер агента Tailscale: Контейнер агента Tailscale запускается в вашем EKS-кластере и отвечает за:

   • Подключение к координационному серверу Tailscale
   • Регистрацию сервисов для их обнаружения
   • Координацию сетевой настройки с подами Nginx

3. Под Nginx: Под Nginx, который:

   • Терминирует TLS-трафик от Tailscale
   • Маршрутизирует трафик на соответствующие IP-адреса внутри вашего EKS-кластера

Процесс установления сетевого подключения

Установление подключения Tailscale выполняется в следующей последовательности:

1. Первичное подключение:

   • Агенты Tailscale на обеих сторонах соединения (окружение инженера ClickHouse и ваш BYOC EKS‑кластер) подключаются к координационному серверу Tailscale
   • Агент EKS‑кластера регистрирует сервис Kubernetes, чтобы сделать его обнаруживаемым
   • Инженеры ClickHouse должны инициировать внутренний запрос на повышение прав доступа, чтобы получить видимость этого сервиса

2. Режим подключения:

   • Direct Mode: агенты пытаются установить прямое соединение через туннель с обходом NAT (NAT traversal)
   • Relay Mode: если установить прямое соединение не удаётся, взаимодействие переходит в relay‑режим через сервер Tailscale DERP (Distributed Encrypted Relay Protocol)

3. Шифрование:

   • Вся передача данных зашифрована сквозным образом
   • Каждый агент Tailscale генерирует собственную пару ключей «открытый/закрытый» (аналогично PKI)
   • Трафик остаётся зашифрованным независимо от того, используется ли прямой или relay‑режим

Механизмы безопасности

Только исходящие подключения:

• Агенты Tailscale в вашем кластере EKS инициируют исходящие подключения к координационным и ретрансляционным серверам Tailscale
• Входящие подключения не требуются — не нужно добавлять правила групп безопасности для разрешения входящего трафика к агентам Tailscale
• Это уменьшает поверхность атаки и упрощает настройку сетевой безопасности

Контроль доступа:

• Доступ контролируется через внутреннюю систему утверждения ClickHouse
• Инженеры должны запрашивать доступ через определённые утверждающие процессы
• Доступ ограничен по времени и автоматически истекает
• Все действия по доступу аудируются и логируются

Аутентификация на основе сертификатов:

• Для доступа к системным таблицам ClickHouse инженеры используют временные, ограниченные по времени сертификаты
• Аутентификация на основе сертификатов заменяет доступ по паролю для всего пользовательского доступа в BYOC
• Доступ ограничен только системными таблицами (не данными клиентов)
• Все попытки доступа логируются в таблице ClickHouse query_log

Устранение неполадок доступа через Tailscale

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

• Kubernetes API Server: Для диагностики отказов монтирования EBS, сетевых проблем на уровне узлов и проблем со здоровьем кластера
• Системным таблицам ClickHouse: Для анализа производительности запросов и выполнения диагностических запросов (доступ к системным таблицам только на чтение)

Процесс доступа для устранения неполадок:

1. Запрос доступа: Дежурные инженеры из назначенной группы запрашивают доступ к экземпляру ClickHouse клиента
2. Одобрение: Запрос проходит через внутреннюю систему согласования с назначенными согласующими лицами
3. Генерация сертификата: Для одобренного инженера генерируется сертификат с ограниченным сроком действия
4. Конфигурация ClickHouse: Оператор ClickHouse настраивает ClickHouse на прием этого сертификата
5. Подключение: Инженеры получают доступ к экземпляру через Tailscale, используя сертификат
6. Автоматическое истечение: Доступ автоматически прекращается по истечении заданного периода времени

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

По умолчанию сервисы управления ClickHouse обращаются к вашему BYOC Kubernetes-кластеру через публичный 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

Мониторинг и аудит

И ClickHouse, и клиенты могут проводить аудит активности доступа через Tailscale:

• Мониторинг ClickHouse: ClickHouse отслеживает запросы на доступ и записывает в журнал все подключения Tailscale
• Аудит со стороны клиента: Клиенты могут отслеживать активность инженеров ClickHouse в своих собственных системах
• Журнал запросов: Весь доступ к системным таблицам через Tailscale фиксируется в таблице query_log в ClickHouse

Для более подробной технической информации о том, как Tailscale реализован в BYOC, см. пост в блоге «Building ClickHouse BYOC on AWS».

Границы сети

В этом разделе рассматриваются различные варианты сетевого трафика в клиентский BYOC VPC и из него:

• Входящий (Inbound): Трафик, входящий в клиентский BYOC VPC.
• Исходящий (Outbound): Трафик, исходящий из клиентского BYOC VPC и отправляемый на внешний ресурс.
• Публичный (Public): Сетевой endpoint, доступный из публичного интернета.
• Приватный (Private): Сетевой endpoint, доступный только через приватные соединения, такие как VPC peering, VPC Private Link или Tailscale.

Входной шлюз Istio развернут за AWS NLB для приема клиентского трафика ClickHouse.

Входящий, публичный или приватный

Входной шлюз Istio выполняет терминaцию TLS. Сертификат, подготовленный CertManager совместно с Let's Encrypt, хранится как секрет (Secret) внутри кластера EKS. Трафик между Istio и ClickHouse шифруется AWS, поскольку они находятся в одном VPC.

По умолчанию входной шлюз общедоступен и использует фильтрацию по списку разрешенных IP-адресов (allow list). Клиенты могут настроить VPC peering, чтобы сделать его приватным и отключить публичные подключения. Настоятельно рекомендуем настроить IP-фильтр для ограничения доступа.

Устранение неполадок с доступом

Входящий, частный

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

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

Исходящий трафик, частный доступ

Скрейпер биллинга собирает данные биллинга из ClickHouse и отправляет их в бакет S3, принадлежащий ClickHouse Cloud.

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

Оповещения

Исходящий трафик, общедоступный

AlertManager настроен на отправку оповещений в ClickHouse Cloud, когда кластер ClickHouse клиента находится в неработоспособном состоянии.

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

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

Исходящий, общедоступный

State Exporter отправляет информацию о состоянии сервиса ClickHouse в очередь SQS, принадлежащую ClickHouse Cloud.