Архитектура

​

Компоненты

• Исполнитель поддерживает исходящий командный канал к конечной точке вашего коннектора и применяет команды жизненного цикла, которые ClickHouse Cloud отправляет для управляемых им сервисов в вашем кластере. Это команды создания, масштабирования, остановки и запуска, перезапуска, резервного копирования и удаления резервных копий, удаления, а также одобренные вами обновления платформы. Любое действие — это вызов Kubernetes API. Он не открывает соединений с ClickHouse и не хранит учетные данные для доступа к вашим бакетам или IAM. Он работает только в управляемом режиме.
• Скрапер с фиксированным интервалом читает разрешенный список системных таблиц ClickHouse и буферизует результаты локально. Затем он отправляет их на конечную точку вашего коннектора вместе с метаданными инфраструктуры и сведениями о работоспособности.
• Средство диагностики поддерживает исходящий командный канал к конечной точке вашего коннектора и выполняет диагностику в режиме только для чтения во время активного сеанса поддержки. Вне сеанса оно не выполняет ничего.

​

Соединения

​

Жизненный цикл сертификата

• Регистрация. clicklink clctl init локально генерирует приватный ключ и запрос на подпись сертификата (CSR). В CSR в качестве common name указывается ваш organization ID, а в качестве единственного DNS SAN — хост вашей конечной точки. Приватный ключ никогда не покидает вашу среду.
• Первичная выдача. init отправляет CSR на конечную точку подписи для регистрации /v1/pcm/cert/sign с аутентификацией по HMAC. Если для вашей организации уже есть действующий сертификат, конечная точка возвращает отказ с кодом 409. В этом случае CLI подскажет, как продолжить с существующим сертификатом либо заменить его, указав --force.
• Автоматическое обновление. Все три демона проверяют срок действия сертификата каждые 12 часов. Когда до истечения остаётся 10 дней, они запрашивают новый сертификат на 30 дней через /v1/pcm/cert/renew (mTLS плюс HMAC). В Kubernetes обновлённый сертификат записывается обратно в Secret clicklink-mtls через grant RBAC с точным указанием имени; на ВМ каждый демон записывает его в /etc/clicklink/tls. Обновление не требует вмешательства оператора.

​

Поток данных

​

Какие данные покидают вашу среду

• Метрики из системных таблиц, включенных в список разрешённых. По умолчанию скрапер использует metric_log, asynchronous_metric_log, tables, warnings и server_settings. Список разрешённых задаётся явной конфигурацией; скрапер не считывает данные за его пределами.
• Метаданные инфраструктуры. Данные о сервисах, инфраструктуре и резервных копиях, синхронизируемые через API. Для управляемого сервиса это его состояние, текущее и ожидаемое количество реплик, а также запущенная версия сервера и версия конфигурации.
• Состояние работоспособности и собственные метрики. Статус компонентов и собственные операционные метрики коннектора. Сигнал активности исполнителя также сообщает, подключён ли его командный канал. Он содержит результат последнего обновления платформы, версии компонентов платформы и дайджест последнего применённого им бандла. При установке на виртуальной машине дополнительно сообщается, находится ли его бандл доступа к Kubernetes в состоянии ok, expiring, expired или отсутствует.
• Результаты выполнения команд. Для каждой команды жизненного цикла, выполняемой исполнителем: прогресс во время сходимости, затем успех или неудача с текстом ошибки в случае сбоя.
• Определения сервисов, которые вы отправляете. clicklink clctl instances create отправляет идентификатор вашей среды, облако и регион, имя сервиса, имена его бакетов и ARN роли IAM, а также ключ идемпотентности. Также отправляются два хеша пароля пользователя default (SHA-256 и двойной SHA-1).
• Результаты сеанса поддержки. Результаты диагностики в режиме только для чтения, выполненной во время включённого вами сеанса и маскированной.

​

Что по умолчанию никогда не покидает ваш контур

• Исходный текст запросов на пути scrape. system.query_log исключена из набора таблиц, опрашиваемых по умолчанию, поскольку её столбцы с запросами могут содержать литеральные значения, а вместе с ними — PII или секреты. Её повторное добавление — это override на уровне конкретного развёртывания. Список разрешённых таблиц для сеансов по умолчанию всё же включает system.processes, где отображается текст выполняющихся запросов; о том, как его урезать, см. сеансы поддержки.
• Данные ваших таблиц и резервные копии. Они остаются в бакетах вашего аккаунта. У исполнителя нет учётных данных для доступа к вашим бакетам, и читать их он не может.
• Учётные данные. init не записывает учётные данные в файлы конфигурации. ClickHouse хранит только bcrypt-хеши паролей пользователей коннектора, а секреты остаются в Kubernetes Secrets или в файлах на хосте, доступных для чтения только пользователю root. Пароль пользователя default для управляемого сервиса генерируется на вашей стороне и показывается один раз; передаются только его хеши. Ни на пути scrape, ни на пути синхронизации учётные данные не передаются.
• Немаскированный вывод средства диагностики. Всё, что возвращает средство диагностики, перед отправкой проходит через шаблоны маскирования (встроенные и ваши собственные). См. сеансы поддержки.

​

Границы доверия

• Границей является ваша среда. ClickHouse Cloud получает только то, что отправляет коннектор: результаты scrape, сигналы работоспособности и статус, результаты команд, а также то, что возвращает активный сеанс поддержки. Он никогда не инициирует входящее соединение.
• Шлюз сеансов принадлежит вам. Он доступен только внутри вашей среды (через kubectl port-forward в Kubernetes или локально на виртуальной машине), если вы сами не откроете его через Ingress. ClickHouse Cloud к нему никогда не подключается.
• Доступ к ClickHouse — только для чтения. Пользователи pcm_scraper и pcm_troubleshooter имеют потабличные grant SELECT, у скрапера дополнительно есть READ ON REMOTE (необходима для clusterAllReplicas()) и один grant SYSTEM FLUSH LOGS, выданный только ему. Grant INSERT, DDL или управления пользователями нет. У исполнителя нет пользователя ClickHouse. Точный перечень приведён в модели привилегий.
• Скрапер и средство диагностики не могут изменять ваш кластер. Их RBAC формируется через Roles в пространствах имен коннектора и сервиса. Эти Roles предоставляют глаголы только для чтения на ресурсах рабочих нагрузок и доступ по точному имени к собственным Secrets коннектора. Разрешений exec, delete или patch нет.
• Исполнитель изменяет состояние кластера в пространствах имен сервисов от имени pcm-executor. Он создаёт и удаляет пространства имен с prefix сервиса (по умолчанию ns-) и удаляет поды, чтобы перезапустить их. Внутри этих пространств имен он записывает объекты ClickHouseCluster, Backup и ScalingOverride, а также Secrets, ServiceAccounts и Services, необходимые сервису. Также он записывает Role и RoleBinding, дающие скраперу доступ на чтение. ValidatingAdmissionPolicy запрещает любую запись от этого ServiceAccount за пределами prefix. Исключения, все в его домашнем пространстве имен, — это обновление его собственного токена, ConfigMap clicklink-instance-registry, а в Kubernetes — обновлённый клиентский сертификат в Secret для mTLS. Если политику невозможно вычислить, она срабатывает на запрет. При чтении допуск не выполняется, поэтому чтение этих семейств ресурсов не ограничено prefix.
• Платформенные пространства имен исполнитель изменяет только как pcm-platform и только во время одобренного вами обновления. Команда clicklink clctl platform approve выпускает токен этой идентичности на 2 часа; он никогда не продлевается. С ним исполнитель может записывать только Развертывания, Services, ConfigMaps, Secrets, Jobs и PodDisruptionBudgets. Пространства имен, CRD, ServiceAccounts, RBAC, конфигурации webhook и допуска, PriorityClasses и StorageClass применяются с вашими учётными данными во время одобрения. См. обновления платформы.
• У исполнителя нет учётных данных к вашим бакетам или IAM. clicklink clctl executor prepare создаёт бакеты данных и backup сервиса и его роль IAM. clicklink clctl executor teardown удаляет их. Обе команды выполняются с вашими учётными данными. Роль доверяет только подам этого сервиса, поэтому принять её не могут ни исполнитель, ни ClickHouse. Его единственные облачные вызовы направляются в Amazon ECR и STS. Он выполняет вход в registry, когда синхронизация платформы или создание сервиса загружает чарт. Во время обновления платформы он проверяет образы под ролью pull только для чтения.
• Сетевая политика. В Kubernetes чарт формирует для каждого демона NetworkPolicy с запретом по умолчанию. Egress разрешён только к DNS, к CIDR, перечисленным вами для конечной точки коннектора, и к CIDR сервера API Kubernetes. Политики скрапера и средства диагностики дополнительно разрешают доступ к ClickHouse Services в пространствах имен, которыми управляет исполнитель (они отбираются по метке, которую он на них проставляет), или к тем, что вы перечислили по имени. В политике исполнителя правила для ClickHouse нет. Если чарт из пакета платформы находятся в Amazon ECR, добавьте диапазоны ECR и STS (или зеркало вашего registry) в allowEgressCIDRs. Без них синхронизация не сможет загрузить чарт при использовании принудительно применяющего CNI. Без принудительно применяющего CNI политика неактивна. См. конфигурацию.
• Усиление защиты хоста на виртуальных машинах. Юниты работают от имени системного пользователя без возможности входа, с ProtectSystem=strict, NoNewPrivileges, путями конфигурации только для чтения и включённым режимом FIPS.