Сеансы поддержки

Сеанс поддержки предоставляет ClickHouse временный доступ для диагностики через коннектор ClickHouse. На этой странице рассказывается, что такое сеанс, как его включать и отключать, что могут делать инженеры поддержки ClickHouse во время сеанса и как провести его аудит.

Что такое сеанс поддержки

Сеанс поддержки — это ограниченное по времени окно, в течение которого средство диагностики принимает команды от инженеров поддержки ClickHouse. Вне сеанса оно отклоняет любые команды, даже если его исходящее WebSocket-соединение установлено. Иного пути выполнения не существует, и ClickHouse не может открыть сеанс за вас. ClickHouse Cloud никогда не подключается к вашей среде извне; он получает только то, что средство диагностики отправляет по своему исходящему каналу. Сеансы управляют исключительно диагностикой. Команды жизненного цикла для сервисов в режиме managed передаются по отдельному каналу исполнителя, который сеанс поддержки не открывает и не ограничивает; см. managed services. Управлять сеансами можно через две точки:

Session gateway — аутентифицируемый API, встроенный в средство диагностики. Он обслуживает POST /v1/clctl/session/enable, POST /v1/clctl/session/disable и GET /v1/clctl/session/status. Для каждого вызова требуется короткоживущий OIDC ID token, адрес электронной почты в котором есть в вашем списке разрешённых.
Локальный файл сеанса при установке на Linux VM — он записывается на хосте с правами root.

Транспорт шлюза зависит от целевой среды. Шлюз на ВМ использует самоподписанный TLS, отпечаток которого закрепляется у каждого оператора. Шлюз в Kubernetes слушает локально в поде по HTTP; доступ к нему осуществляется через kubectl port-forward (туннель идёт поверх TLS API server) или через Входной шлюз, который терминирует TLS с сертификатом, выпущенным CA. Конфигурация сеансов, включая список разрешённых, задаётся во время выполнения clicklink clctl init.

Включение и отключение сеансов

Kubernetes
Linux VM

Шлюз прослушивает порт 8443 на поде средства диагностики. При наличии доступа к кластеру подключитесь к нему через проброс порта:

CONNECTOR_NAMESPACE='clicklink'   # пространство имен коннектора, выбранное при инициализации
kubectl -n "${CONNECTOR_NAMESPACE}" port-forward statefulset/clicklink-connector-troubleshooter 8443:8443

Затем в другом терминале включите сеанс:

clicklink clctl troubleshoot session enable \
  --gateway-url http://localhost:8443 \
  --duration 4h \
  --reason "<ticket reference>"

Таким же образом проверьте его состояние или завершите сеанс:

clicklink clctl troubleshoot session status --gateway-url http://localhost:8443
clicklink clctl troubleshoot session disable --gateway-url http://localhost:8443

OIDC-идентификатор вызывающей стороны должен быть в списке разрешенных операторов. Неаутентифицированные или не включенные в список вызывающие стороны получают код 401 или 403, а шлюз записывает попытку в журнал. Чтобы операторы могли работать без учетных данных кластера, предоставьте доступ к шлюзу через опциональный входной шлюз chart, который терминирует TLS с сертификатом, выданным CA; см. configuration.

При наличии root-доступа к хосту управляйте сеансом напрямую. Демон и CLI атомарно читают и записывают файл состояния /var/lib/clicklink/session.json:

sudo clicklink clctl troubleshoot session enable --duration 4h --reason "<ticket reference>"
sudo clicklink clctl troubleshoot session status
sudo clicklink clctl troubleshoot session disable

Шлюз также доступен на ВМ для вызывающих сторон без root-доступа. Он использует самоподписанный TLS, поэтому каждый пользователь сеанса один раз закрепляет отпечаток сертификата шлюза:

clicklink clctl troubleshoot gateway trust \
  --gateway-url https://<vm-host>:8443 \
  --gateway-fingerprint <sha256-fingerprint>

Закрепленный отпечаток хранится в ~/.clicklink/clctl.yaml. Соединение завершается ошибкой, если предъявленный сертификат ему не соответствует. Если же шлюз предъявляет сертификат, выданный вашим собственным CA, передавайте соответствующий набор CA с помощью --gateway-ca в каждой команде сеанса.

Истечение срока действия сеанса

Сеансы завершаются автоматически. По умолчанию длительность составляет 4 часа; session enable --duration принимает значение до 24 часов. По истечении срока действия или сразу после выполнения session disable средство диагностики перестаёт принимать команды. Отключение немедленно отзывает доступ: без перезапуска и без координации с ClickHouse.

Список разрешённых операторов

Каждый вызов шлюза авторизуется по списку разрешённых адресов электронной почты операторов. При сверке используется адрес, подтверждённый валидированным токеном OIDC, и никогда — значение, предоставленное клиентом.

Kubernetes: задайте clctl.gateway.allowedOperators в файле оверлея values. Chart преобразует список в ConfigMap, поэтому изменение values и выполнение helm upgrade обновляют список разрешённых без перезапуска пода.
Linux VM: список разрешённых хранится в /etc/clicklink/allowed-operators.txt; файл записывается командой clicklink clctl init на основе указанных вами адресов электронной почты операторов.

На обеих целевых платформах шлюз перечитывает файл при следующем запросе, если с момента последнего чтения прошло 30 секунд. Изменения вступают в силу без перезапуска.

Что могут делать операторы во время сеанса

Пока сеанс активен, инженеры поддержки ClickHouse могут выполнять команды двух видов. SQL-запросы только для чтения выполняются в ваших кластерах от имени пользователя pcm_troubleshooter, привилегии которого ограничены списком разрешенных таблиц сеанса. Кроме того, средство диагностики отклоняет любой оператор, который не начинается с SELECT, WITH, SHOW, DESCRIBE или EXPLAIN. Пользователю выданы только потабличные привилегии SELECT — без прав на запись, DDL или администрирование. Список разрешенных таблиц по умолчанию охватывает таблицы system, такие как system.parts, system.merges, system.replicas, system.metrics и system.settings. Таблицы system.query_log и system.text_log добавить в него нельзя: демон отклоняет конфигурацию, в которой они перечислены, поэтому привилегии на них не выдаются никогда. При этом список по умолчанию включает system.processes, в столбце query которой отображается текст выполняющихся операторов. Удалите ее из troubleshooter.allowedTables (оверлей Helm) или troubleshooter.allowed_tables (файл конфигурации ВМ), если текст выполняющихся запросов ни при каких условиях не должен быть виден в сеансе. Просмотр объектов Kubernetes только для чтения — это операции get, list и watch для подов, статуса подов, логов подов, сервисов, configmap, событий, PersistentVolumeClaim, развертываний, statefulset и replicaset в предоставленных пространствах имен. Access bundles привязаны к Kubernetes ServiceAccount на обеих целевых площадках установки. Без подготовленного bundle средство диагностики сразу отклоняет команды типа kubectl. Исполнитель подготавливает scraper для managed service, но не средство диагностики; см. сеансы поддержки для managed service. RBAC средства диагностики не содержит разрешений exec, delete или patch, поэтому операторы не могут открыть оболочку в ваших подах или что-либо изменить в рамках сеанса. Полный перечень привилегий и RBAC приведен в справочнике модель привилегий.

Журнал аудита

Каждая команда, выполненная в ходе сеанса, добавляется в файл /var/log/clicklink/troubleshoot-audit.log — по одному объекту JSON на строку (NDJSON). Заблокированные команды также записываются, при этом в blocked_by указывается причина (например, session inactive). submitted_by — это ID организации в канале команд: ID вашей собственной организации. Конкретный инженер ClickHouse фиксируется на стороне ClickHouse Cloud, а не в этом файле. Запись о команде сеанса выглядит так:

{
  "timestamp": "2026-06-22T22:30:00.123456789Z",
  "command_id": "11111111-2222-4333-8444-555555555555",
  "submitted_by": "<org-id>",
  "command_type": "sql",
  "command_text": "SELECT database, table, active, count() FROM system.parts GROUP BY ALL",
  "instance_id": "analytics",
  "status": "completed",
  "duration_ms": 42,
  "output_lines": 12
}

status содержит результат выполнения команды: completed, error или rejected. Вызовы шлюза записываются отдельно. Каждый вызов, включая отклоненные, фиксируется как структурированная строка clctl.gateway в собственном журнале средства диагностики: в journal на ВМ и в журнале контейнера в Kubernetes. Строка содержит submitted_by (адрес электронной почты, подтвержденный проверенным токеном, а не значение, переданное клиентом) и command_type (clctl.session.enable, clctl.session.disable или clctl.session.status). Также она содержит reason (значение --reason, указанное при включении), remote_addr и status. Поле status принимает значения ok, unauthorized, forbidden, rate_limited, bad_request, conflict или error, поэтому отказы в доступе также отражаются в журнале. Локальные изменения сеанса на ВМ не являются записями журнала аудита. Вызывающий пользователь хоста записывается как enabled_by в /var/lib/clicklink/session.json и отображается командой session status. На ВМ журнал аудита читается командой clicklink clctl troubleshoot audit tail. В Kubernetes журнал находится внутри пода средства диагностики, а в образе контейнера нет командной оболочки, поэтому вызовите собственный считыватель бинарного файла через kubectl exec:

CONNECTOR_NAMESPACE='clicklink'   # the connector namespace you chose at init
kubectl -n "${CONNECTOR_NAMESPACE}" exec statefulset/clicklink-connector-troubleshooter -- \
  /clicklink clctl troubleshoot audit tail

Журнал аудита — это обычный файл внутри вашей среды; отправляйте его в свою SIEM-систему так же, как любой другой лог хоста или контейнера.

Маскирование

Всё, что возвращает средство диагностики, маскируется перед тем, как покинуть вашу среду. Встроенные шаблоны охватывают IPv4- и IPv6-адреса, Bearer-токены, ключи доступа AWS, адреса электронной почты, JWT, закрытые SSH-ключи и учетные данные в строках подключения. Их можно расширить или переопределить в /etc/clicklink/redaction-patterns.yaml; запись с тем же именем, что и встроенный шаблон, заменяет его. Демон не запускается при недопустимом файле шаблонов, а clicklink clctl preflight проверяет этот файл, поэтому некорректная конфигурация маскирования вызывает явную ошибку.

Архитектура: все подключения, устанавливаемые коннектором, и потоки данных в рамках сеансов.
Конфигурация: настройки шлюза, списка разрешённых адресов и маскирования данных.
FAQ: кратко об отзыве доступа, аудите и исходящем трафике данных.

Начало работы

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

Собственное облако

Данные и интеграции

Подключение и выполнение запросов

Управление доступом

Безопасность и соблюдение требований

Мониторинг и резервные копии

Инструменты и агенты ИИ

Cloud API

Оплата

Поддержка

ClickHouse Private

Что такое сеанс поддержки

Включение и отключение сеансов

Истечение срока действия сеанса

Список разрешённых операторов

Что могут делать операторы во время сеанса

Журнал аудита

Маскирование

​Что такое сеанс поддержки

​Включение и отключение сеансов

​Истечение срока действия сеанса

​Список разрешённых операторов

​Что могут делать операторы во время сеанса

​Журнал аудита

​Маскирование

​Связанные страницы

Что такое сеанс поддержки

Включение и отключение сеансов

Истечение срока действия сеанса

Список разрешённых операторов

Что могут делать операторы во время сеанса

Журнал аудита

Маскирование

Связанные страницы