Skip to main content

​
Роли IAM в AWS

​
Bootstrap IAM role

Роль IAM для начальной настройки имеет следующие разрешения:
  • Операции EC2 и VPC: требуются для настройки VPC и кластеров EKS.
  • Операции S3 (например, s3:CreateBucket): нужны для создания бакетов для хранилища ClickHouse BYOC.
  • Операции IAM (например, iam:CreatePolicy): нужны, чтобы контроллеры могли создавать дополнительные роли (подробности см. в следующем разделе).
  • Операции EKS: ограничены ресурсами, имена которых начинаются с префикса clickhouse-cloud.

​
Дополнительные роли IAM, создаваемые контроллером

Помимо ClickHouseManagementRole, создаваемой через CloudFormation, контроллер создаст ещё несколько ролей. Эти роли принимают на себя приложения, работающие в EKS-кластере клиента:
  • Роль State Exporter
    • Компонент ClickHouse, который передаёт информацию о состоянии сервиса в ClickHouse Cloud.
    • Требует разрешения на запись в очередь SQS, принадлежащую ClickHouse Cloud.
  • Load-Balancer Controller
    • Стандартный контроллер AWS для балансировщика нагрузки.
    • Контроллер EBS CSI для управления томами сервисов ClickHouse.
  • External-DNS
    • Распространяет конфигурацию DNS в Route 53.
  • Cert-Manager
    • Выпускает TLS-сертификаты для доменов сервиса BYOC.
  • Cluster Autoscaler
    • При необходимости изменяет размер группы узлов.
  • Хранилище мониторинга (Thanos)
    • Принимается на себя рабочими нагрузками Prometheus и Thanos в вашем кластере.
    • Записывает и читает метрики долговременного хранения, ограничиваясь бакетом мониторинга в вашем собственном аккаунте.
Роли K8s-control-plane и k8s-worker предназначены для использования сервисами AWS EKS. Наконец, data-plane-mgmt позволяет компоненту Control Plane ClickHouse Cloud приводить к желаемому состоянию необходимые пользовательские ресурсы, такие как ClickHouseCluster и Istio Virtual Service/Gateway.

​
Сервисные аккаунты GCP

​
Сервисный аккаунт Bootstrap

Сервисному аккаунту Bootstrap назначаются пользовательские роли уровня проекта со следующими разрешениями:
  • Общие: Базовые разрешения на чтение и идентификацию.
  • VPC: Управление VPC, подсетями, маршрутизацией и подключениями Private Service Connect, которые используются для размещения вашей инфраструктуры BYOC.
  • Кластер: Управление кластерами GKE и ресурсами внутри кластера.
  • Хранилище: Используется для управления бакетами Cloud Storage, применяемыми для резервных копий ClickHouse, общего состояния и данных мониторинга.
  • Роль IAM: Управление сервисными аккаунтами и пользовательскими ролями внутри проекта. Эта роль не дает возможности создавать ключи сервисных аккаунтов, привязывать политики организации или изменять какие-либо ресурсы в других проектах.

​
Дополнительные сервисные аккаунты, создаваемые контроллером

Помимо сервисного аккаунта clickhouse-management, созданного через Terraform в рамках онбординга, при подготовке вашего первого сервиса BYOC Control Plane ClickHouse (аутентифицируясь как clickhouse-management) создает в вашем проекте дополнительные сервисные аккаунты для определенных внутрикластерных рабочих нагрузок. Каждый из них создается с минимальным набором разрешений для одной конкретной задачи.
  • Сервисный аккаунт среды выполнения узлов GKE
    • Привязывается к каждой виртуальной машине узла GKE в вашем кластере BYOC.
    • Используется Кубелетом, локальными для узла агентами и коллекторами Cloud Operations для отправки журналов и метрик, а также подсистемой загрузки образов для скачивания образов контейнеров.
  • Сервисный аккаунт скрейпера биллинга
    • Используется автономной рабочей нагрузкой скрейпера для сбора телеметрии биллинга.
  • Сервисный аккаунт мониторинга
    • Целевой сервисный аккаунт для стека мониторинга, работающего в вашем кластере. Используется для чтения и записи в долговременное хранилище метрик в бакете GCS, выделенном для этого развертывания.
  • Сервисный аккаунт управления средой выполнения ClickHouse
    • Используется контроллером управления плоскостью данных среды выполнения ClickHouse, который выполняет операции второго дня, такие как управление конечными точками Private Service Connect, корректировка жизненного цикла бакета и ротация сервисных аккаунтов.
State exporter, который публикует события состояния сервисов и резервных копий в ClickHouse Cloud, намеренно отсутствует в этом списке: в GCP его публикующим сервисным аккаунтом является аккаунт, принадлежащий ClickHouse, в проекте ClickHouse, а не аккаунт, созданный в вашем проекте. В вашем проекте создается привязка Workload Identity, которая позволяет внутрикластерному сервисному аккаунту state-exporter олицетворять его. Ключевой материал при этом не используется, а сервисный аккаунт, публикующий данные в Pub/Sub, не имеет никаких разрешений в вашем проекте.

​
Роли и удостоверения в Azure

​
Сервисный субъект онбординга

Онбординг с помощью модуля Terraform для Azure создает в вашем тенанте мультитенантное приложение как Enterprise Application (сервисный субъект) в соответствии с рекомендациями Azure по межтенантной аутентификации. Сервисному субъекту назначается пользовательская роль с минимально необходимыми привилегиями, действующая в рамках целевой подписки и предоставляющая следующие разрешения:
  • Сеть: управление VNet, подсетями, общедоступными IP-адресами, NAT-шлюзами, группами сетевой безопасности и зонами DNS, в которых размещена ваша инфраструктура BYOC.
  • Кластер: управление кластерами AKS и пулами узлов.
  • Хранилище: управление аккаунтами хранилища и контейнерами BLOB-объектов, используемыми для данных ClickHouse, резервных копий и данных мониторинга.
  • Идентификация: управление назначаемыми пользователем управляемыми идентификаторами и их учетными данными федеративной идентификации в рамках подписки.
  • Авторизация: управление определениями пользовательских ролей и назначениями ролей. Все разрешения ограничены целевой подпиской — роль не может управлять ресурсами в других подписках или тенантах.

​
Дополнительные управляемые удостоверения, создаваемые контроллером

При подготовке сервисов BYOC Control Plane ClickHouse создаёт в вашей подписке управляемые идентификаторы, назначаемые пользователем. Каждое из них федеративно связано с определённым сервисным аккаунтом Kubernetes (Workload Identity) и имеет узкий набор разрешений для одной конкретной цели:
  • Удостоверение для каждого сервиса
    • Используется каждым сервисом ClickHouse для доступа к собственному аккаунту хранилища, содержащему данные таблиц и резервные копии, через пользовательскую роль для хранилища BLOB-объектов, область действия которой ограничена этим аккаунтом хранилища.
    • При восстановлении сервиса из резервной копии он также получает доступ только для чтения к контейнеру резервных копий исходного сервиса.
  • Общее удостоверение инфраструктуры
    • Используется контроллером управления плоскостью данных среды выполнения ClickHouse для операций второго дня, таких как управление сервисами Private Link.
  • Удостоверение мониторинга
    • Федеративно связано с рабочей нагрузкой Thanos в вашем кластере через пользовательскую роль, область действия которой ограничена доступом к хранилищу мониторинга.
    • Выполняет запись и чтение долговременного хранения метрик в вашей собственной подписке.
Как и в случае с GCP, state exporter намеренно отсутствует в этом списке: его публикующее удостоверение — это назначаемый пользователем управляемый идентификатор, принадлежащий ClickHouse и находящийся в подписке ClickHouse. На вашей стороне создаются лишь учётные данные федеративной идентификации, позволяющие сервисному аккаунту state-exporter внутри кластера получать для него токены без обмена секретами. Удостоверение, публикующее данные в Service Bus, не имеет никаких разрешений в вашей подписке.
Это отличается от AWS, где публикующая роль создаётся в вашем собственном аккаунте и принимает роль на стороне ClickHouse для доступа к очереди. В GCP и Azure публикующее удостоверение полностью находится на стороне ClickHouse, а ваш кластер лишь федеративно связывается с ним, поэтому для этого потока нет дополнительных разрешений в вашем аккаунте, которые вам нужно было бы проверять. Сам исходящий трафик учтён в разделе сетевые границы.
Последнее изменение 26 сентября 2026 г.