> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-revert-104359-revert-104251-parquet-single.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Сетевая безопасность BYOC > Развертывание ClickHouse в собственной облачной инфраструктуре export const Image = ({img, alt, size = "lg"}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; return
{alt}
; };
## Соединения между плоскостью управления ClickHouse и вашей VPC BYOC
Плоскость управления ClickHouse Cloud поддерживает несколько типов подключений, необходимых для работы и сопровождения вашего развертывания BYOC: | Назначение | Тип соединения | Примечания | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Повседневные операции — API-сервер Kubernetes** | Публичное подключение с фильтрацией по IP (по умолчанию), или приватное через Tailscale или AWS VPC Lattice | Сервисы управления взаимодействуют с API-сервером Kubernetes (EKS/GKE/AKS) через публичную сеть; доступ ограничен списками разрешённых IP-адресов. После первоначального развертывания при желании можно переключиться на частный доступ через Tailscale или, в AWS, через VPC Lattice. | | **Повседневные операции — API облачного провайдера** | VPC ClickHouse → облачный провайдер | Сервисы управления вызывают API вашего облачного провайдера (например, EKS и EC2 в AWS, GKE в GCP, AKS в Azure) из собственной среды ClickHouse Cloud. Это не задействует ни вашу VPC/VNet, ни Tailscale. | | **Устранение неполадок — сервис ClickHouse** | Tailscale | Инженеры ClickHouse получают доступ к сервису ClickHouse (например, к системным таблицам) для диагностики через Tailscale. | | **Устранение неполадок — API-сервер Kubernetes** | Tailscale | Инженеры ClickHouse получают доступ к API-серверу Kubernetes для диагностики кластера через Tailscale. |
## API облачного провайдера и API Kubernetes
Два разных пути управления легко спутать. Они различаются источником трафика, способом аутентификации и возможностью использования Tailscale: | | API облачного провайдера | API-сервер Kubernetes | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Чем управляет** | Облачными ресурсами: самим кластером Kubernetes, группами узлов, балансировщиками нагрузки, бакетами хранилища, DNS | Рабочими нагрузками внутри кластера: подами ClickHouse, операторами и их конфигурацией | | **Куда направляется трафик** | Общедоступные конечные точки API облачного провайдера (например, `eks.amazonaws.com`, `ec2.amazonaws.com`) — этот трафик никогда не попадает в ваш VPC/VNet | Конечная точка API вашего кластера в вашем аккаунте | | **Аутентификация** | AWS: межаккаунтный `sts:AssumeRole` для `ClickHouseManagementRole` и роли управления конкретной инфраструктурой, защищённый внешним идентификатором. GCP: impersonation сервисного аккаунта (без ключей). Azure: федеративная идентификация для сервисного субъекта ClickHouse (учётные данные не передаются) | Краткосрочные учётные данные Kubernetes, выдаваемые через API облачного провайдера (например, `eks:GetToken` с использованием принятой роли) | | **Возможность использования Tailscale** | **Отсутствует.** Эти вызовы направляются из сети ClickHouse Cloud напрямую к облачному провайдеру и не могут маршрутизироваться через Tailscale или вашу сеть | Публичная конечная точка по умолчанию ограничена исходящими IP-адресами ClickHouse; её можно переключить на частный доступ через Tailscale или, в AWS, через VPC Lattice | | **Журнал аудита** | AWS CloudTrail (или эквивалентные сервисы GCP/Azure) в вашем аккаунте фиксирует каждый вызов с принятой идентичностью | В AWS журналы control plane EKS, включая журнал аудита, передаются в группу журналов CloudWatch в вашем аккаунте (см. [платные сервисы AWS](/ru/products/bring-your-own-cloud/reference/billable-aws-services)); в GCP и Azure обратитесь в службу поддержки, чтобы подтвердить или включить аудит control plane для вашего кластера | Иными словами, только трафик API Kubernetes и трафик для устранения неполадок могут использовать Tailscale. Вызовы API облачного провайдера всегда исходят из сети ClickHouse Cloud и завершаются на конечных точках провайдера — маршрутизировать их через Tailscale невозможно, поскольку они вообще не попадают в вашу сеть.
### Ограничения разрешений по источнику сетевого трафика
Если в вашей организации ограничено принятие роли 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 используется **только для операций управления и устранения неполадок**. Он **никогда не используется для передачи трафика запросов** или доступа к данным клиентов. Все данные клиентов остаются в вашей VPC и никогда не передаются через Tailscale.
### Как работает Tailscale в BYOC
BYOC Tailscale Для каждого сервиса или конечной точки, к которым нужен доступ через 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 к данным](/ru/products/bring-your-own-cloud/reference/clickhouse-data-access).
### Доступ сервисов управления
По умолчанию сервисы управления ClickHouse получают доступ к вашему Kubernetes-кластеру BYOC через публичный IP-адрес API-сервера, к которому разрешён доступ только с IP-адресов шлюза NAT ClickHouse. **Необязательная настройка частной конечной точки**: * Вы можете настроить API-сервер Kubernetes так, чтобы он использовал только частную конечную точку * В этом случае сервисы управления получают доступ к API-серверу через Tailscale (аналогично доступу для устранения неполадок у пользователей) или, в AWS, через VPC Lattice (см. [Частное подключение к API Kubernetes](/ru/products/bring-your-own-cloud/configuration/configurations#k8s-api-private-connection)) * По умолчанию публичная конечная точка (доступ к которой разрешён только с IP-адресов NAT ClickHouse) сохраняется как резервный механизм для экстренной диагностики и задач поддержки; после проверки частного доступа её можно полностью отключить по согласованию с ClickHouse)
### Поток сетевого трафика
**Схема соединения Tailscale**: 1. Агент Tailscale в вашем кластере Kubernetes → сервер координации Tailscale (исходящее соединение) 2. Агент Tailscale на машине инженера → сервер координации Tailscale (исходящее соединение) 3. Между агентами устанавливается прямое соединение или соединение через ретранслятор 4. Зашифрованный трафик проходит через установленный туннель 5. Под Nginx в EKS терминирует TLS и маршрутизирует трафик к внутренним сервисам **Передача данных клиентов отсутствует**: * Соединения Tailscale используются только для управления и устранения неполадок * Трафик запросов и данные клиентов никогда не проходят через Tailscale * Все данные клиентов остаются в пределах вашего VPC Более подробную техническую информацию о том, как Tailscale реализован в BYOC, см. в [статье в блоге Building ClickHouse BYOC on AWS](https://clickhouse.com/blog/building-clickhouse-byoc-on-aws#tailscale-connection). О том, какие данные могут читать инженеры ClickHouse после подключения и как ClickHouse аудирует этот доступ, см. в разделе [доступ ClickHouse к данным](/ru/products/bring-your-own-cloud/reference/clickhouse-data-access).
## Сетевые границы
В этом разделе рассматриваются различные типы сетевого трафика в 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](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/encrypting-data-at-rest-and--in-transit.html#:~:text=All%20network%20traffic%20between%20AWS,supported%20Amazon%20EC2%20instance%20types), поскольку они находятся в одной VPC. По умолчанию входной шлюз общедоступен с фильтрацией по списку разрешённых IP-адресов. Клиенты могут настроить пиринг VPC, чтобы сделать его приватным и отключить публичные подключения. Мы настоятельно рекомендуем настроить [IP-фильтр](/ru/products/cloud/guides/security/connectivity/setting-ip-filters), чтобы ограничить доступ.
### Доступ для устранения неполадок
*Входящий, приватный* Инженерам ClickHouse Cloud требуется доступ для устранения неполадок через Tailscale. Для развертываний BYOC им предоставляется аутентификация по сертификатам по модели just-in-time. Полную политику доступа см. в разделе [доступ ClickHouse к данным](/ru/products/bring-your-own-cloud/reference/clickhouse-data-access).
### Скрапер биллинга
*Исходящий, приватный* Скрапер биллинга собирает данные о биллинге из 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 отправляет в очередь SQS, принадлежащую ClickHouse Cloud, сведения о состоянии сервиса ClickHouse и резервных копий (событиях эксплуатационного статуса, а не содержимом резервных копий).