Skip to main content
На этой странице приведена справочная информация по безопасности коннектора ClickHouse: полный перечень устанавливаемых им соединений, точные привилегии, которыми он обладает, действия, которые он архитектурно не может выполнять, а также сведения об атрибуции каждого действия. О том, как эти компоненты взаимодействуют, см. раздел «Архитектура».

Возможности коннектора

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

Ниже приведен полный список подключений, которые устанавливает коннектор. Все они инициируются из вашей среды. Для входящих подключений коннектор предоставляет только локальные порты проверки работоспособности и метрик, а также дополнительный шлюз сеансов. Другие порты не прослушиваются, и ClickHouse Cloud никогда не подключается к вашей среде: он может только отвечать через исходящий WebSocket средства устранения неполадок.

Привилегии ClickHouse

При провизионировании для каждого компонента создаётся один пользователь с доступом только для чтения. Единственное исключение — указанная ниже привилегия scraper’а SYSTEM FLUSH LOGS: она не позволяет читать или изменять данные, а лишь принудительно записывает в хранилище уже буферизованные записи из таблиц логов. Пользователи создаются с IDENTIFIED WITH bcrypt_hash, поэтому в SQL провизионирования содержится только хеш bcrypt с солью; пароль в открытом виде хранится лишь в файле учётных данных, который демон читает во время выполнения. Привилегии в точности следующие, с наборами таблиц по умолчанию:
READ ON REMOTE требуется, поскольку scrape-запросы оборачивают каждую системную таблицу в clusterAllReplicas(). SYSTEM FLUSH LOGS необходимо выдать в глобальной области видимости, поскольку ClickHouse отклоняет более узкие области действия этой привилегии; ClickHouse учитывает её только для системных таблиц *_log, поэтому выданная привилегия шире фактически доступной возможности.
Разрешение system.user_directories предоставлено обоим пользователям исключительно для диагностики: clicklink clctl preflight запускается с учетными данными самого коннектора и проверяет, как экземпляр хранит пользователей ClickHouse — реплицированно или локально. В этой таблице содержатся метаданные конфигурации хранилища пользователей, а не пользовательские данные; она не входит ни в набор целей для сбора метрик, ни в список разрешённых таблиц сеанса, поэтому ни один путь вывода сбора метрик или сеанса её не читает. Без этого разрешения единственная соответствующая предварительная проверка будет отмечена как пропущенная, а всё остальное продолжит выполняться. Помимо SELECT для каждой таблицы, единственная системная привилегия скрапера — SYSTEM FLUSH LOGS: она принудительно записывает буферизованные записи из системных таблиц *_log на диск, чтобы при сборе были доступны актуальные данные, и больше ничего не делает; ClickHouse применяет её только к таблицам логов, хотя выдать эту привилегию можно только на глобальном уровне. Привилегии для INSERT, DDL, управления пользователями, настроек или управления процессами отсутствуют. Если экземпляр совместно используется вторым развертыванием connector, его пользователи получают суффикс (pcm_scraper_<suffix>) с теми же наборами привилегий.

Kubernetes RBAC

Chart создает только роли, ограниченные Пространством имен; РольКластера и ClusterRoleBinding не создаются.

Чего коннектор не может делать

  • Не записывает данные или состояние в ClickHouse. Указанные выше привилегии не включают INSERT, DDL, а также привилегии для управления пользователями, настройками или процессами; единственная системная привилегия — SYSTEM FLUSH LOGS для скрапера — лишь обеспечивает сохранение в таблицах логов уже буферизованных данных. Коннектор не может изменять данные, схемы, пользователей или настройки.
  • Не выполняет команды. RBAC не включает pods/exec; коннектор не может запускать команды в ваших подах.
  • Не удаляет и не применяет patch. RBAC разрешает две мутации: update с точным именем для собственного mTLS секрета коннектора и create для serviceaccounts/token, который выпускает краткоживущие токены для собственных ServiceAccounts коннектора и не изменяет ни один сохраненный объект.
  • Нет области действия уровня кластера. Каждая роль привязана к пространству имен; коннектор не может перечислять или читать ресурсы за пределами предоставленных вами пространств имен.
  • Никакого входящего трафика. ClickHouse Cloud никогда не открывает соединение с вашей средой. Единственный путь выполнения команд — исходящий WebSocket средства устранения неполадок; оно отклоняет любые команды, пока не активен включенный вами сеанс поддержки. Даже во время сеанса область действия ограничена с обеих сторон: запросы ClickHouse ограничены списком разрешённых таблиц, а query_log и text_log отклоняются валидатором независимо от конфигурации; доступ к Kubernetes отдельно ограничен представлениями только для чтения и журналами подов, предоставляемыми ролями в пределах пространства имен.

Что требует ваших действий

  • Сеансы поддержки. Интерактивное устранение неполадок возможно только в включённом вами сеансе: по умолчанию он ограничен 4 часами, максимум — 24 часами. Отключение действует немедленно. См. сеансы поддержки.
  • Список разрешённых операторов. Каждый запрос к шлюзу должен содержать токен OIDC, подтверждённый адрес электронной почты которого указан в вашем списке разрешённых. Пустой список разрешённых означает запрет доступа. Вы управляете этим списком; см. руководство по настройке.
  • Доступность шлюза. Шлюз сеанса отключён, пока вы его не включите, и доступен только через проброс порта, если вы не настроите Входной шлюз. На виртуальной машине каждый оператор должен закрепить отпечаток его самоподписанного сертификата, прежде чем команды сеанса смогут подключиться к нему.
  • Исходящий сетевой трафик. При использовании CNI с принудительным применением политик у коннектора нет исходящего трафика, пока вы не добавите CIDR конечных точек в список разрешённых в NetworkPolicy чарта.

Как определяется принадлежность доступа

  • Идентификация развертывания. Общее имя клиентского mTLS-сертификата — это ID вашей организации, а с хостом конечной точки связано одно DNS-имя, поэтому каждое API-подключение можно однозначно отнести к вашей организации. Сертификат продлевается автоматически внутри демона; ключевой материал не обрабатывается операторами.
  • Целостность запроса. Каждый API-запрос также содержит подпись HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...), вычисляемую по методу, пути, временной метке и хешу тела с использованием пары ключей, выданной при регистрации.
  • Идентификация оператора. Вызовы шлюза связываются с адресом электронной почты, подтвержденным OIDC ID-токеном оператора и проверенным по JWKS вашего провайдера идентификации; если токен доступен, самостоятельно указанному имени никогда не доверяют.
  • Журнал аудита. Каждый вызов шлюза и каждая команда устранения неполадок — независимо от того, были они приняты или заблокированы, — добавляются в журнал аудита NDJSON: записи шлюза содержат подтвержденный адрес электронной почты оператора, изменения локального сеанса VM — имя пользователя хоста, выполнившего вызов, а команды сеанса — идентификатор организации, переданный по аутентифицированному каналу. Для просмотра используйте clicklink clctl troubleshoot audit tail; см. справочник CLI.

Настройки минимизации данных по умолчанию

  • query_log по умолчанию исключён из сбора метрик. Его столбцы содержат необработанный SQL с литеральными значениями, которые могут включать персональные данные или секреты, поэтому он не покидает ваш периметр, пока вы намеренно не добавите его.
  • Средство устранения неполадок читает только таблицы из списка разрешённых, а валидатор безусловно запрещает query_log и text_log, поэтому история запросов никогда не доступна для чтения. Список разрешённых по умолчанию включает system.processes (текст выполняемого запроса); ограничьте список разрешённых таблиц для сеанса (troubleshooter.allowedTables в Kubernetes, troubleshooter.allowed_tables на виртуальной машине), если эта информация должна оставаться скрытой во время сеансов.
  • Все выходные данные средства устранения неполадок маскируются встроенными шаблонами для IPv4- и IPv6-адресов, Bearer-токенов, ключей доступа AWS, адресов электронной почты, JWT, закрытых ключей SSH и учётных данных в строках подключения, а также любыми определёнными вами шаблонами. Демон не запускается при недействительном файле шаблонов, вместо того чтобы работать без маскирования.
  • Учётные данные сводятся к минимуму при хранении. SQL для провизионирования содержит хеши bcrypt, но никогда не содержит пароли в открытом виде; токен регистрации никогда не записывается в командную строку, на диск или в журналы; ключи хранятся в Kubernetes Secrets или файлах с режимом 0600.
Последнее изменение 26 августа 2026 г.