Skip to main content

​
Компоненты

Коннектор ClickHouse запускает два демона, встроенных в бинарный файл clicklink:
  • Скрапер с заданным интервалом считывает список разрешённых системных таблиц ClickHouse, локально буферизует результаты и отправляет их на конечную точку коннектора вместе с метаданными инфраструктуры и информацией о работоспособности.
  • Средство диагностики поддерживает исходящий канал команд к конечной точке коннектора и выполняет диагностику только для чтения во время активного сеанса поддержки. Вне сеанса оно ничего не выполняет.
В Kubernetes оба компонента работают как рабочие нагрузки, развёрнутые Helm-чартом clicklink-connector в выбранном пространстве имён (по умолчанию — clicklink). На виртуальной машине Linux они работают как модули systemd clicklink-scraper и clicklink-troubleshooter от имени непривилегированного системного пользователя clicklink.

​
Подключения

Все подключения, устанавливаемые коннектором, являются исходящими. Полный список: Каждый API-запрос содержит заголовок Authorization с подписью HMAC-SHA256, вычисленной по методу, пути, временной метке и хешу тела. Поэтому запросы невозможно воспроизвести повторно или изменить при передаче даже внутри канала TLS. Для входящих подключений коннектор предоставляет только локальные порты проверки работоспособности и метрик, а также подключаемый шлюз сеансов, описанный на странице сеансов поддержки. Плоскость управления ClickHouse никогда не подключается ни к одному из них.

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

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

​
Поток данных

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

  • Метрики из системных таблиц, включенных в список разрешённых. По умолчанию скрапер использует metric_log, asynchronous_metric_log, tables, warnings и server_settings. Список разрешённых задаётся явной конфигурацией; скрапер не считывает данные за его пределами.
  • Метаданные инфраструктуры. Данные об экземплярах, инфраструктуре и резервных копиях, синхронизируемые через API.
  • Состояние работоспособности и собственные метрики. Статус компонентов и собственные операционные метрики коннектора.
  • Результаты сеанса поддержки. Результаты диагностики в режиме только для чтения, выполненной во время включённого вами сеанса и маскированной.

​
Что по умолчанию никогда не покидает систему

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

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

  • Ваша среда — это граница доверия. ClickHouse Cloud получает только данные, отправленные скрапером, и данные, возвращаемые в ходе активного сеанса поддержки. Он никогда не инициирует подключение к вашей среде.
  • Шлюз сеанса находится под вашим контролем. Он доступен только внутри вашей среды (через kubectl port-forward в Kubernetes или локально на ВМ), если только вы не откроете к нему доступ через входной шлюз. Плоскость управления ClickHouse никогда к нему не подключается.
  • Доступ к ClickHouse — только для чтения. Пользователи pcm_scraper и pcm_troubleshooter имеют привилегии SELECT для отдельных таблиц, а также одну системную привилегию, доступную только скраперу, для сброса таблиц логов на диск — и ничего более; привилегии INSERT, DDL и управления пользователями отсутствуют. Точный перечень приведен в модели привилегий.
  • Доступ к Kubernetes ограничен пространством имен. Все разрешения RBAC выдаются через Roles в пространствах имен коннектора и экземпляра, с разрешениями только на чтение для ресурсов рабочей нагрузки и доступом к собственным Secrets коннектора строго по имени. Разрешения exec, delete и patch отсутствуют.
  • Сетевая политика. В Kubernetes chart может создать NetworkPolicy, запрещающую весь исходящий трафик коннектора, кроме трафика к указанным вами CIDR. Применение политики зависит от CNI в кластере, поддерживающего ее применение; без него политика не действует. См. конфигурацию.
  • Защита хоста на ВМ. Модули запускаются от имени системного пользователя без возможности входа в систему, с ProtectSystem=strict, NoNewPrivileges, путями конфигурации только для чтения и включенным режимом FIPS.
Точные привилегии и правила RBAC коннектора см. в справочнике модели привилегий. Если кластерами вместо вас управляет ClickHouse, модель доверия отличается; см. страницы архитектуры BYOC и привилегий BYOC.
Последнее изменение 26 августа 2026 г.