> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Привилегия BYOC

> Развертывание ClickHouse в собственной облачной инфраструктуре

<div id="aws-iam-roles">
  ## Роли IAM в AWS
</div>

<div id="bootstrap-iam-role">
  ### Bootstrap IAM role
</div>

Роль IAM для начальной настройки имеет следующие разрешения:

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

<div id="additional-iam-roles-created-by-the-controller">
  ### Дополнительные роли IAM, создаваемые контроллером
</div>

Помимо `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**
  * При необходимости изменяет размер группы узлов.

Роли **K8s-control-plane** и **k8s-worker** предназначены для использования сервисами AWS EKS.

Наконец, **`data-plane-mgmt`** позволяет компоненту Control Plane ClickHouse Cloud приводить к желаемому состоянию необходимые пользовательские ресурсы, такие как `ClickHouseCluster` и Istio Virtual Service/Gateway.

<div id="gcp-service-accounts">
  ## Сервисные аккаунты GCP
</div>

<div id="bootstrap-service-account">
  ### Сервисный аккаунт Bootstrap
</div>

Сервисному аккаунту Bootstrap назначаются пользовательские роли уровня проекта со следующими разрешениями:

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

<div id="additional-service-accounts-created-by-the-controller">
  ### Дополнительные сервисные аккаунты, создаваемые контроллером
</div>

Помимо сервисного аккаунта `clickhouse-management`, созданного через Terraform в рамках онбординга, при подготовке вашего первого сервиса BYOC Control Plane ClickHouse (аутентифицируясь как `clickhouse-management`) создает в вашем проекте дополнительные сервисные аккаунты для определенных внутрикластерных рабочих нагрузок. Каждый из них создается с минимальным набором разрешений для одной конкретной задачи.

* **Сервисный аккаунт среды выполнения узлов GKE**
  * Привязывается к каждой виртуальной машине узла GKE в вашем кластере BYOC.
  * Используется Кубелетом, локальными для узла агентами и коллекторами Cloud Operations для отправки журналов и метрик, а также подсистемой загрузки образов для скачивания образов контейнеров.
* **Сервисный аккаунт скрейпера биллинга**
  * Используется автономной рабочей нагрузкой скрейпера для сбора телеметрии биллинга.
* **Сервисный аккаунт мониторинга**
  * Целевой сервисный аккаунт для стека мониторинга, работающего в вашем кластере. Используется для чтения и записи в долговременное хранилище метрик в бакете GCS, выделенном для этого развертывания.
* **Сервисный аккаунт управления средой выполнения ClickHouse**
  * Используется контроллером управления плоскостью данных среды выполнения ClickHouse, который выполняет операции второго дня, такие как управление конечными точками Private Service Connect, корректировка жизненного цикла бакета и ротация сервисных аккаунтов.

<div id="azure-roles-and-identities">
  ## Роли и удостоверения в Azure
</div>

<div id="onboarding-service-principal">
  ### Сервисный субъект онбординга
</div>

Онбординг с помощью [модуля Terraform для Azure](https://github.com/ClickHouse/terraform-byoc-onboarding/tree/main/modules/azure) создает в вашем тенанте мультитенантное приложение как Enterprise Application (сервисный субъект) в соответствии с рекомендациями Azure по межтенантной аутентификации. Сервисному субъекту назначается пользовательская роль с минимально необходимыми привилегиями, действующая в рамках целевой подписки и предоставляющая следующие разрешения:

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

<div id="additional-managed-identities-created-by-the-controller">
  ### Дополнительные управляемые удостоверения, создаваемые контроллером
</div>

При подготовке сервисов BYOC Control Plane ClickHouse создаёт в вашей подписке управляемые удостоверения, назначаемые пользователем. Каждое из них федеративно связано с определённым сервисным аккаунтом Kubernetes (Workload Identity) и имеет узкий набор разрешений для одной конкретной цели:

* **Удостоверение для каждого сервиса**
  * Используется каждым сервисом ClickHouse для доступа к собственному аккаунту хранения, содержащему данные таблиц и резервные копии, через настраиваемую роль для хранилища BLOB-объектов, область действия которой ограничена этим аккаунтом хранения.
  * При восстановлении сервиса из резервной копии он также получает доступ только для чтения к контейнеру резервных копий исходного сервиса.
* **Общее удостоверение инфраструктуры**
  * Используется контроллером управления плоскостью данных среды выполнения ClickHouse для операций второго дня, таких как управление сервисами Private Link.