> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Сетевая безопасность BYOC > Развертывание ClickHouse в собственной облачной инфраструктуре export const Image = ({img, alt, size = "lg", background}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined; return
{alt}
; };
## Соединения между плоскостью управления ClickHouse и вашей VPC BYOC
Плоскость управления ClickHouse Cloud поддерживает несколько типов подключений, необходимых для работы и сопровождения вашего развертывания BYOC: | Назначение | Тип соединения | Примечания | | - | - | - | | **Повседневные операции — API-сервер Kubernetes** | Публичная конечная точка по умолчанию, с разными механизмами ограничения в зависимости от облака, или приватное подключение через Tailscale либо собственный частный канал облачного провайдера | Сервисы управления взаимодействуют с API-сервером Kubernetes (EKS/GKE/AKS) через его публичную конечную точку. Способ ограничения такого доступа зависит от облака — список разрешённых IP в AWS, облачный IAM в GCP и Azure; см. [Доступность API-сервера Kubernetes](#kubernetes-api-server-exposure). После первоначального развертывания при желании можно переключиться на частный доступ — через Tailscale в любом облаке или через собственный частный канал облачного провайдера: AWS VPC Lattice, конечную точку GKE на основе DNS с отключённой IP-конечной точкой или Azure Private Link. | | **Повседневные операции — 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 или вашу сеть | По умолчанию публичная конечная точка — в AWS ограничена исходящими IP-адресами ClickHouse, в GCP и Azure контролируется облачным IAM (см. [Доступность API-сервера Kubernetes](#kubernetes-api-server-exposure)); её можно переключить на частный доступ через Tailscale или собственный частный канал облачного провайдера (см. [Частное подключение к API Kubernetes](/ru/products/bring-your-own-cloud/configuration/configurations#k8s-api-private-connection)) | | **Журнал аудита** | AWS CloudTrail (или эквивалентные сервисы GCP/Azure) в вашем аккаунте фиксирует каждый вызов с принятой идентичностью | В AWS журналы плоскости управления EKS, включая журнал аудита, передаются в группу журналов CloudWatch в вашем аккаунте (см. [платные сервисы AWS](/ru/products/bring-your-own-cloud/reference/billable-aws-services)); в GCP и Azure обратитесь в службу поддержки, чтобы подтвердить или включить аудит плоскости управления для вашего кластера | Иными словами, только трафик API Kubernetes и трафик для устранения неполадок могут использовать Tailscale. Описанные выше управляющие вызовы всегда исходят из сети ClickHouse Cloud и завершаются на конечных точках провайдера — маршрутизировать их через Tailscale невозможно, поскольку они вообще не попадают в вашу сеть. API облачного провайдера вызываются и с другой стороны — контроллерами, работающими внутри вашего собственного кластера: контроллером балансировщика нагрузки, драйвером CSI, автоскейлером, контроллером DNS и cert-manager. Эти вызовы используют внутрикластерные идентичности и уходят через ваш собственный путь исходящего трафика, поэтому в журнале аудита они отображаются с другой идентичностью и другим адресом источника, нежели управляющие вызовы. См. [Исходящие подключения](#outbound-connections).

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

Если в вашей организации ограничено принятие роли 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

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 через публичную конечную точку API-сервера, доступ к которой в каждом облаке ограничивается по-разному: в AWS — списком разрешённых IP, содержащим только адреса шлюза NAT ClickHouse, а в GCP и Azure — облачным IAM. Подробности по каждому облаку см. в разделе [Доступность API-сервера Kubernetes](#kubernetes-api-server-exposure). **Необязательная настройка частной конечной точки**: * Вы можете настроить API-сервер Kubernetes так, чтобы он использовал только частную конечную точку * В этом случае сервисы управления получают доступ к API-серверу через Tailscale (аналогично доступу для устранения неполадок у пользователей) или, в AWS, через VPC Lattice (см. [Частное подключение к API Kubernetes](/ru/products/bring-your-own-cloud/configuration/configurations#k8s-api-private-connection)) * По умолчанию публичная конечная точка сохраняется как резервный механизм для экстренной диагностики и задач поддержки; после проверки частного доступа её можно полностью отключить по согласованию с ClickHouse

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

**Схема соединения Tailscale**: 1. Агент Tailscale в вашем кластере Kubernetes → сервер координации Tailscale (исходящее соединение) 2. Агент Tailscale на машине инженера → сервер координации Tailscale (исходящее соединение) 3. Между агентами устанавливается прямое соединение или соединение через ретранслятор 4. Зашифрованный трафик проходит через установленный туннель 5. Под Nginx в вашем кластере Kubernetes терминирует TLS и маршрутизирует трафик к внутренним сервисам **Передача данных клиентов отсутствует**: * Соединения Tailscale используются только для управления и устранения неполадок * Трафик запросов и данные клиентов никогда не проходят через Tailscale * Все данные клиентов остаются в вашем собственном облачном аккаунте Более подробную техническую информацию о том, как 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).

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

Этот раздел описывает 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.

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

Далее на этой странице используются облачно-нейтральные названия. В таблице показано, чему они соответствуют у каждого провайдера: | Понятие | AWS | GCP | Azure | | - | - | - | - | | Сеть BYOC | VPC | VPC network | VNet | | Kubernetes cluster | EKS | GKE | AKS | | Балансировщик нагрузки для входящего клиентского трафика | Network Load Balancer | External passthrough Network Load Balancer | Azure Load Balancer | | Сервис частных конечных точек | PrivateLink endpoint service | Подключение сервиса GCP Private Service Connect | Private Link Service | | Объектное хранилище | S3 | Cloud Storage | Blob Storage | | Тома узлов/журналов | EBS | Persistent Disk | Managed Disks | | Путь исходящего трафика | NAT gateway в каждой availability zone со статическими Elastic IP | Cloud NAT с вручную зарезервированными статическими IP | NAT Gateway с назначенными публичными IP | | Частный путь к storage API провайдера | S3 gateway VPC endpoint | Private Google Access | магистральная сеть Azure через NAT | | Аудит Cloud API | CloudTrail | Cloud Audit Logs | Azure Activity log | Исходящий трафик в публичный интернет покидает вашу сеть BYOC через небольшой фиксированный набор NAT-адресов — и так в любом облаке, поэтому вы можете зафиксировать их в собственных правилах контроля исходящего трафика. Актуальные значения для вашего развертывания запросите у команды ClickHouse. В AWS и GCP исключение составляет трафик к собственным storage API провайдера: он идет по частному пути из строки выше и до NAT gateway не доходит.

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

| Listener | Порты | Источник | Назначение | Ваши средства контроля | | - | - | - | - | - | | Публичный балансировщик нагрузки клиентского входящего трафика (по умолчанию при VPC, управляемом ClickHouse) | TCP 8443 (HTTPS-интерфейс) и 9440 (native-протокол поверх TLS); порт 443 также маршрутизируется на HTTPS-интерфейс | Ваши клиенты ClickHouse | Трафик запросов. TLS терминируется на входящем шлюзе Istio внутри вашей собственной сети | IP access list; может быть полностью отключен после того, как настроен частный путь | | Частный балансировщик нагрузки клиентского входящего трафика (по умолчанию при управляемом клиентом VPC) | Те же порты, что и выше | Указанные вами сети | Трафик запросов из пиринговых сетей | Контролируемый вами список разрешенных диапазонов источников | | Сервис конечной точки для частных конечных точек (опционально) | Те же порты, что и выше | Частные конечные точки, создаваемые вами в собственной учетной записи, проекте или подписке | Трафик запросов без выхода в интернет | Каждая конечная точка должна быть зарегистрирована в ClickHouse по своему endpoint ID, иначе подключение будет невозможно — см. [Подключение к сервису BYOC](/ru/products/bring-your-own-cloud/configuration/connect) | | API-сервер Kubernetes | TCP 443 | Сервисы управления ClickHouse | Управление кластером | Различается в зависимости от облака — см. [Доступность API-сервера Kubernetes](#kubernetes-api-server-exposure) | | Конечная точка мониторинга (появляется после включения частного балансировщика нагрузки) | TCP 443 | Сети, имеющие частный доступ к вашей сети BYOC | Запросы PromQL и федерация к внутрикластерному стеку Prometheus и Thanos | Доступна только по частным путям и никогда через публичный интернет. Аутентификация не требуется, поэтому средством контроля доступа служит сетевая достижимость — см. [обсервабилити](/ru/products/bring-your-own-cloud/reference/observability-aws) | | Peer-ретранслятор Tailscale (опционально, по умолчанию отключен) | UDP 40000 | Peer-узлы tailnet ClickHouse | Улучшает обход NAT для управляющей сети | Принимает только взаимно аутентифицированные peer-узлы WireGuard; полезная нагрузка остается зашифрованной сквозным образом | На этих балансировщиках нагрузки иногда видны еще два порта, но они не предназначены для клиентов: TCP 15021 обслуживает собственные проверки работоспособности провайдера для входящего шлюза и не передает трафик запросов, а интерфейс MySQL (порт 3306) в BYOC в настоящее время не открыт — см. [FAQ](/ru/products/bring-your-own-cloud/reference/faq). Сертификат входящего шлюза выпускается cert-manager публичным центром сертификации ACME (Let's Encrypt) с использованием проверки DNS-01 и хранится как Kubernetes secret внутри вашего собственного кластера. Трафик между входящим шлюзом и подами ClickHouse не покидает вашу сеть BYOC — см. [Внутрисетевой трафик](#intra-network-traffic). Какой из двух балансировщиков нагрузки включен по умолчанию, зависит от вашей сетевой модели. При VPC, управляемом ClickHouse, каждый сервис получает публичный балансировщик нагрузки, защищенный IP access list, а частный балансировщик нагрузки можно включить дополнительно. При управляемом клиентом VPC настройки по умолчанию противоположны: включен только частный балансировщик нагрузки, и у ваших сервисов нет публичной точки входа, пока вы ее не добавите. См. [Подключение к сервису BYOC](/ru/products/bring-your-own-cloud/configuration/connect). Везде, где включен публичный путь, мы настоятельно рекомендуем настроить [IP-фильтр](/ru/products/cloud/guides/security/connectivity/setting-ip-filters); вы также можете добавить частный путь — см. [Настройка частной сети](/ru/products/bring-your-own-cloud/onboarding/network) — и затем полностью отключить публичный доступ. Обратите внимание, что IP-фильтрация применяется на уровне входящего прокси, поэтому при сканировании порты балансировщика нагрузки могут выглядеть открытыми, тогда как подключения из неуказанных источников будут отклонены. Помимо перечисленных выше listener'ов, нет ни SSH, ни bastion-хоста, ни постоянных административных учетных данных. Трафик запросов ни в одном направлении не проходит через инфраструктуру, принадлежащую ClickHouse: ваши клиенты подключаются напрямую к входящему шлюзу внутри вашей собственной сети. Для отдельных развертываний могут быть включены дополнительные порты протоколов — текущие примеры: native-доступ с аутентификацией по сертификату и Arrow Flight, — поэтому уточните точный набор портов для вашего развертывания у вашей команды ClickHouse, прежде чем составлять правила межсетевого экрана на основе этой таблицы.

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

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

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

*входящий, Private* Инженеры ClickHouse Cloud подключаются к вашему развертыванию для устранения неполадок только через Tailscale и никогда через публичный интернет — во всех облаках. Доступ выдается по принципу just-in-time и на основе сертификатов: инженер запрашивает его через внутренний процесс согласования, платформа выпускает краткосрочные учетные данные для конкретного инженера, срок действия которых истекает автоматически. Общей административной учетной записи и постоянного доступа не существует. Полное описание политики, включая перечень таблиц, доступных инженерам для чтения, см. в разделе [доступ ClickHouse к данным](/ru/products/bring-your-own-cloud/reference/clickhouse-data-access).

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

| Пункт назначения | Порты | Инициатор | Назначение | Что пересекает границу | | - | - | - | - | - | | Региональные API вашего облачного провайдера | TCP 443 | Контроллеры внутри кластера: контроллер балансировщика нагрузки, драйвер CSI, autoscaler, контроллер DNS, cert-manager | Штатная работа кластера в вашем собственном аккаунте | Только вызовы Cloud API | | Ваше собственное объектное хранилище | TCP 443 | Серверы ClickHouse, задания резервного копирования и стек мониторинга, если включено долговременное хранение | Data parts, резервные копии и долговременное хранение метрик | Ваши данные — они остаются в вашем аккаунте. В AWS и GCP трафик в пределах одного региона идёт по приватному пути, описанному в разделе [Эквиваленты провайдеров](#provider-equivalents), и минует NAT gateway; в Azure он остаётся в магистральной сети Azure, но всё равно выходит через ваш NAT gateway. Стек мониторинга выполняет запись под собственной identity — подробнее в разделе [Привилегии](/ru/products/bring-your-own-cloud/reference/privilege) | | Бакет телеметрии, принадлежащий ClickHouse | TCP 443 | Sidecar-скрапер метрик | Учёт потребления, мониторинг состояния, автомасштабирование | Системные метрики и операционные метаданные — см. [Скрапер биллинга](#billing-scraper) | | Очередь сообщений, принадлежащая ClickHouse | TCP 443 | State exporter | Статус сервиса, отображаемый в консоли ClickHouse Cloud | Метаданные состояния — см. [Состояние сервиса](#service-state) | | Реестр контейнеров, принадлежащий ClickHouse | TCP 443 | Загрузка образов kubelet, доставка чартов | Подписанные образы и чарты плоскости данных | Только загрузка (pull) | | Служба координации Tailscale и ретрансляторы DERP | TCP 443, WireGuard поверх UDP | Агенты Tailscale в вашем кластере | Устанавливает управляющую сеть (mesh) | Зашифрованный управляющий канал | | Публичный центр сертификации | TCP 443, DNS | cert-manager | Выпуск TLS-сертификатов для конечных точек ваших сервисов | Запросы на подпись сертификата — только открытые ключи | | Приём алертов в ClickHouse Cloud | TCP 443 | AlertManager | Оповещает SRE-команду ClickHouse, когда с вашим кластером есть проблемы | Имя алерта и идентификатор сервиса — см. [Алерты](#alerts) |

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

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

Оповещения

*Outbound, Public* AlertManager настроен на отправку оповещений в ClickHouse Cloud, когда ваш ClickHouse cluster работает некорректно. Полезная нагрузка оповещений в BYOC намеренно сокращена до имени оповещения и идентификатора сервиса. Полный набор данных мониторинга остаётся в вашем собственном аккаунте в любом облаке. Здесь важно различать два случая, так как границы у них разные: * **Непрерывный экспорт.** Сокращённая телеметрия использования и состояния, описанная в разделе [сборщик данных для биллинга](#billing-scraper), а также эти полезные нагрузки оповещений — единственные данные обсервабилити, которые записываются в системы, принадлежащие ClickHouse. Prometheus remote-write в ClickHouse Cloud в сборках BYOC отключён. * **Чтение на месте.** Панели мониторинга ClickHouse и — при одобренной эскалации — инженеры ClickHouse обращаются с запросами к Prometheus stack внутри кластера и к вашим журналам через Tailscale — см. [Tailscale Private Network](#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](https://docs.aws.amazon.com/whitepapers/latest/logical-separation/encrypting-data-at-rest-and--in-transit.html), [GCP](https://cloud.google.com/docs/security/encryption-in-transit) и [Azure](https://learn.microsoft.com/azure/security/fundamentals/encryption-overview). Исходящий трафик по умолчанию не ограничивается на уровне security group, правил firewall и network security group; фактически используются только те пункты назначения, которые перечислены в разделе [Исходящие подключения](#outbound-connections). При необходимости для каждого сервиса можно включить отдельный 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.