Модель привилегий

Что именно может и чего не может коннектор ClickHouse: identities, исходящие подключения, ClickHouse grants, Kubernetes RBAC, доступ к облаку, атрибуция и минимизация данных

Эта страница — справочник по безопасности коннектора ClickHouse: его identities, соединения, точный перечень привилегий, структурные ограничения, а также то, как атрибутируется каждое действие. О том, как эти элементы связаны между собой, см. architecture.

​

Identities

• Клиентский сертификат mTLS коннектора, в котором в качестве common name указан ваш Organization ID, аутентифицирует каждый демон на вашей конечной точке коннектора. Команда clicklink clctl instances create использует тот же сертификат и HMAC key при обращении к конечной точке.
• pcm_scraper и pcm_troubleshooter — это ClickHouse users только для чтения, под которыми подключаются scraper и средство диагностики. У исполнителя нет ClickHouse user.
• ServiceAccounts для средства диагностики, по одному на каждое подготовленное развертывание, дают доступ к представлениям Kubernetes только для чтения, которые может использовать сеанс поддержки.
• pcm-executor — это Kubernetes ServiceAccount исполнителя для управления жизненным циклом managed services. ValidatingAdmissionPolicy ограничивает его запись пространствами имен сервисов.
• pcm-platform — это идентичность исполнителя для обновлений платформы. Ваша команда clicklink clctl platform approve выпускает для него токен на 2 часа и никогда его не продлевает; между подтверждениями у исполнителя нет доступа на запись к платформенному слою.
• Роль IAM для каждого сервиса (по умолчанию CH-S3-<service>-<region>-00-Role) создается командой clicklink clctl executor prepare с вашими учётными данными. Она ограничена бакетами данных и backup этого сервиса, и доверие к ней есть только у Kubernetes ServiceAccount этого сервиса, поэтому ни исполнитель, ни ClickHouse не могут ее assume.
• Instance profile EC2-виртуальной машины коннектора выполняет assume роли ECR puller только для чтения в вашей среде для прямого доступа к платформе — как для входа для загрузки чарта, так и для проверок image. CLI подтверждения использует тот же путь через instance profile; AWS-профили на workstation или SSO учётные данные его не заменяют. Другие чарт-реестры ECR используют ambient AWS учётные данные. Image pulls выполняются на ваших узлах под их собственной pull-ролью. Исполнитель не хранит учётные данные для ваших бакетов или IAM и не выполняет вызовов S3 или IAM. См. registry credentials.
• Ваши собственные учётные данные применяют каждый grant: grant доступа для исполнителя при init --managed, бакеты и роль при prepare, половина разрешений для каждого обновления платформы при approve и очистка при teardown.

​

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

​

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

Каждое соединение, которое открывает коннектор, инициируется внутри вашей среды. Полный перечень:

Назначение	Protocol	Цель
Конечная точка вашего коннектора	HTTPS с mTLS, каждый request подписан HMAC	POST /v1/metrics, /v1/self-metrics, /v1/status, /v1/instance/sync, /v1/infra/sync, /v1/backup/sync, /v1/pcm/cert/renew; из clicklink clctl — POST /v1/pcm/instances (отправка определения сервиса)
Конечная точка вашего коннектора	Исходящий WebSocket, /v1/commands/ws	Командный канал средства диагностики, доступ к которому определяется состоянием сеанса поддержки
Конечная точка вашего коннектора	Исходящий WebSocket, /v1/commands/ws/executor	Командный канал исполнителя: команды управления жизненным циклом управляемых сервисов и их результаты
Ваша enrollment конечная точка	HTTPS (enrollment token или HMAC; без mTLS)	Погашение токена и подписание сертификата (/v1/pcm/cert/sign) на этапе установки
Ваши кластеры ClickHouse	Собственный протокол ClickHouse	Запросы только для чтения от имени pcm_scraper и pcm_troubleshooter, а также выражение сброса логов от scraper (см. привилегии); исполнитель не открывает соединений с ClickHouse
API-сервер Kubernetes	HTTPS	Чтение в пределах пространства имён и запросы токенов ServiceAccount для scraper и средства диагностики (обе цели); операции записи исполнителя внутри пространств имён сервисов и, во время одобренного обновления платформы, внутри пространств имён платформы; чтение и update по точному имени собственного Secret с mTLS-данными коннектора для сохранения обновлённых сертификатов (только для установок в Kubernetes; на виртуальной машине обновления записываются в локальные файлы TLS)
Amazon ECR	HTTPS, read-only pull role, которую assume с использованием instance profile ВМ EC2 с коннектором для прямого доступа к платформе; ambient AWS учётные данные для других ECR-registry с чартами	Вход в registry, когда синхронизация или создание платформы загружает чарт из ECR; DescribeImages во время обновления платформы для подтверждения того, что образы существуют
AWS STS	HTTPS, instance profile ВМ EC2 с коннектором для прямого доступа к платформе; настроенная цепочка AWS учётных данных для других ECR-registry с чартами	Assume read-only pull role для входа в registry с чартами платформы при прямом доступе и для проверки образов; также может предоставлять учётные данные для входа в другие ECR. ECR и STS — единственные облачные вызовы API, выполняемые исполнителем
Container registry, с узлов вашего кластера	HTTPS	Загрузка образов для управляемых сервисов и компонентов платформы через read-only pull role, которую ClickHouse предоставляет зарегистрированным вами ролям узлов, либо из вашего собственного registry после импорта образов
Конечная точка JWKS вашего провайдера идентификации	HTTPS	Проверка токенов оператора — только при включённом session gateway

Во входящем направлении каждый демон открывает один локальный порт проверки работоспособности, на котором также отдаются его метрики Prometheus, плюс включаемый по желанию session gateway. Локальный командный API исполнителя привязан только к loopback. Больше ничего не прослушивается. ClickHouse Cloud никогда не подключается к вашей среде: он может только отвечать по двум исходящим WebSocket-соединениям.

​

Grant ClickHouse

При провизионировании для каждого наблюдающего компонента создаётся один пользователь с доступом только для чтения. Пользователи создаются с IDENTIFIED WITH bcrypt_hash, поэтому в SQL провизионирования содержится только хеш bcrypt с солью. Пароль в открытом виде хранится лишь в файле учётных данных, который демон читает во время выполнения. Строка ALTER USER после каждого CREATE USER выполняет ротацию хеша при --force. У исполнителя нет пользователя ClickHouse, и он никогда не подключается к ClickHouse. Grant в точности следующие, с наборами таблиц по умолчанию:

CREATE USER IF NOT EXISTS `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_scraper` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`metric_log` TO `pcm_scraper`;
GRANT SELECT ON `system`.`server_settings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`tables` TO `pcm_scraper`;
GRANT SELECT ON `system`.`warnings` TO `pcm_scraper`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_scraper`;
GRANT READ ON REMOTE TO `pcm_scraper`;
GRANT SYSTEM FLUSH LOGS ON *.* TO `pcm_scraper`;

READ ON REMOTE требуется, поскольку scrape-запросы оборачивают каждую системную таблицу в clusterAllReplicas(). SYSTEM FLUSH LOGS — единственная привилегия системного уровня. Она заставляет системные таблицы *_log записывать в хранилище уже буферизованные записи, чтобы при сборе метрик были видны актуальные данные; читать или изменять что-либо она не позволяет. ClickHouse принимает эту привилегию только в глобальной области видимости и учитывает её только для таблиц логов, поэтому выданный grant шире фактически доступной возможности.

CREATE USER IF NOT EXISTS `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';
ALTER USER `pcm_troubleshooter` IDENTIFIED WITH bcrypt_hash BY '<bcrypt-hash>';

GRANT SELECT ON `system`.`asynchronous_metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`build_options` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`clusters` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`databases` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`detached_parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`disks` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`events` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`formats` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`functions` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`grants` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`merges` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`metrics` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`mutations` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_columns` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`parts_summary` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`processes` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replicas` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`replication_queue` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`roles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profile_elements` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`settings_profiles` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`storage_policies` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`table_engines` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`tables` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`users` TO `pcm_troubleshooter`;
GRANT SELECT ON `system`.`user_directories` TO `pcm_troubleshooter`;

Grant system.user_directories предоставлено обоим пользователям исключительно для диагностики. clicklink clctl preflight запускается с учетными данными самого коннектора и проверяет, хранит ли инстанс пользователей ClickHouse реплицированно или локально. В этой таблице содержатся метаданные конфигурации хранилища пользователей, а не пользовательские данные. Она не входит ни в набор целей для сбора метрик, ни в список разрешённых таблиц сеанса, поэтому ни один путь вывода сбора метрик или сеанса её не читает. Без этого grant соответствующая предварительная проверка будет отмечена как пропущенная, а всё остальное продолжит выполняться.

Привилегии для INSERT, DDL, управления пользователями, настроек или управления процессами отсутствуют. Если экземпляр совместно используется вторым развертыванием connector, его пользователи получают суффикс (pcm_scraper_<suffix>) с теми же наборами привилегий.

​

Kubernetes RBAC

​

Scraper и средство диагностики

У scraper и средства диагностики нет РолиКластера или ClusterRoleBinding. Chart создает роли, ограниченные Пространством имен, в Пространстве имен коннектора, а каждый пакет доступа для отдельного экземпляра создает роль в Пространстве имен ClickHouse или сервиса этого экземпляра.

Ресурсы	Операции	Область действия
secrets	get	Только точно указанные имена: секрет mTLS, секрет HMAC и секрет пакета доступа для каждого экземпляра
secrets	update	Только секрет mTLS с точно указанным именем, чтобы демоны могли сохранять автоматически обновляемый клиентский сертификат
serviceaccounts/token	create	Только точно указанные имена: собственный ServiceAccount компонента и ServiceAccount пакета доступа для каждого экземпляра
clickhouseclusters, backups (clickhouse.com)	get, list, watch	Только для scraper, через роль для отдельного экземпляра в каждом Пространстве имен ClickHouse или сервиса, для синхронизации статуса сервиса и резервных копий
pods, pods/log, pods/status, services, configmaps, events, persistentvolumeclaims	get, list, watch	Только для средства устранения неполадок
deployments, statefulsets, replicasets (apps)	get, list, watch	Только для средства устранения неполадок

​

Исполнитель

В управляемом режиме команда clicklink clctl init --managed (или clicklink clctl executor access grant --cluster с последующим apply --cluster) применяет grant исполнителя с вашими credentials. Этот grant включает ServiceAccount pcm-executor (в пространстве имен коннектора на Kubernetes и в clicklink-system при установке на ВМ), одну привязанную к нему РольКластера и ValidatingAdmissionPolicy pcm-executor-prefix-guard.

Глаголы выдаются на уровне всего кластера, поскольку RBAC не позволяет задать префикс пространства имен. Поэтому политика допуска запрещает любую запись от pcm-executor, направленную в пространство имен за пределами префикса сервиса (по умолчанию ns-). В собственном пространстве имен исполнителя разрешены три операции записи: renewal его собственного токена, ConfigMap clicklink-instance-registry, который читает scraper, и, на Kubernetes, обновленный клиентский certificate, записываемый обратно в Secret clicklink-mtls. Политика распространяется только на этот ServiceAccount и использует failurePolicy: Fail и validationActions: [Deny]. ClusterRoleBinding применяется последней — после политики и ее привязки, — чтобы при частично примененном grant исполнитель остался вовсе без разрешений, а не с незащищенными.

На ВМ команда clicklink clctl executor prepare дополнительно применяет bundle для каждого сервиса. Такой bundle состоит из ServiceAccount pcm-executor внутри ns-<name>, Role с теми же семействами ресурсов и РолиКластера, ограниченной глаголами get и delete для этого единственного пространства имен. Если такой bundle есть, исполнитель использует его для сервиса, иначе — общекластерный grant. На Kubernetes под всегда действует от имени ServiceAccount pcm-executor из пространства имен коннектора.

Ресурсы	Глаголы	Для чего
clickhouseclusters (clickhouse.com)	get, list, watch, create, update, patch, delete	Определение сервиса, которое формирует ClickHouse Cloud; перезапуски добавляют к нему annotation, удаление убирает его
backups (clickhouse.com)	get, list, watch, create, delete	Backup и удаление backup
scalingoverrides (clickhouse.com)	get, create, update	Scaling до количества реплик, запрошенного ClickHouse Cloud
pods	get, delete	Перезапуск одного пода
secrets	get, list, create, update, delete	Secrets с credentials сервиса
serviceaccounts	get, create, update, patch, delete	ServiceAccount сервиса, несущий annotation роли IAM
services	get, list, create	Внутренний load balancer сервиса, если он запрошен
namespaces	get, create, update, delete	Создание пространства имен сервиса и его удаление вместе с сервисом; только имена с префиксом
roles, rolebindings (rbac.authorization.k8s.io)	get, create, update, patch	Доступ scraper только для чтения внутри каждого пространства имен сервиса; механизм предотвращения escalation в Kubernetes ограничивает их разрешениями, которыми исполнитель уже обладает. Для средства диагностики исполнитель ничего не provision; см. support sessions для managed service
serviceaccounts/token	create	Только точные имена: pcm-executor и ServiceAccount scraper, для renewal токена
secrets	get, update	Только mTLS Secret коннектора, по точному имени, чтобы сохранить обновленный клиентский certificate. Только для установок на Kubernetes, выдается через Role из chart в пространстве имен коннектора
configmaps	get, update, patch, create	ConfigMap clicklink-instance-registry в пространстве имен коннектора. Только для установок на Kubernetes, выдается через Role из chart; get, update и patch привязаны к имени, а политика допуска ограничивает create этим именем

Для get, list и watch допуск не выполняется, поэтому чтение исполнителем этих семейств ресурсов префиксом не ограничено.

​

Идентичность платформы

clicklink clctl platform approve применяет ту часть обновления платформы, которая относится к разрешениям, используя ваши учетные данные: Пространства имен, CustomResourceDefinitions, ServiceAccounts, РолиКластера и ClusterRoleBindings, Roles и RoleBindings, конфигурации вебхуков и допуска, PriorityClasses, а также StorageClass. Затем он применяет ServiceAccount pcm-platform, его РольКластера, ValidatingAdmissionPolicy pcm-platform-scope-guard и привязку, после чего выпускает связанный токен со сроком действия 2 часа.

С этим токеном исполнитель может записывать только deployments, services, configmaps, secrets, jobs и poddisruptionbudgets, и только в тех пространствах имен платформы, которые разрешает scope guard. Он может читать pods, events, namespaces, serviceaccounts, CustomResourceDefinitions, объекты RBAC, конфигурации вебхуков, StorageClasses и PriorityClasses, чтобы убедиться, что часть с разрешениями уже на месте, прежде чем что-либо применять. Он никогда не обладает правами escalate, bind или impersonate, никогда не записывает ресурсы кластерной области видимости или объекты RBAC и не может выпустить или продлить собственный токен. Токен авторизует ровно один бандл: одобренный вами дайджест записывается в ServiceAccount, и исполнитель отклоняет любой другой.

​

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

• Никакой записи в данные или состояние ClickHouse. Перечисленные выше grant не содержат ни INSERT, ни DDL, ни привилегий управления пользователями, настройками или процессами. Единственный grant системного класса — SYSTEM FLUSH LOGS у scraper’а — лишь заставляет таблицы логов сохранить то, что уже находится в буфере. У исполнителя нет пользователя ClickHouse. Ни один компонент не может изменять данные, схемы, пользователей или настройки через ClickHouse.
• Никакого exec. Ни в одном RBAC нет pods/exec; ни один компонент не может выполнять команды в ваших подах.
• Никакой записи за пределами пространств имен сервисов и платформы. У scraper’а и средства диагностики нет ни delete, ни patch. Их единственные изменения — это update по точному имени для собственного mTLS-Secret коннектора и create для serviceaccounts/token, который выпускает короткоживущие токены для их собственных ServiceAccount и не изменяет ни одного сохраненного объекта. Допуск отклоняет записи исполнителя за пределами префикса сервиса, а его записи в платформу возможны, только пока действителен выпущенный вами токен.
• Нет разрешения выдавать разрешения. Ваши учетные данные применяют пространства имен платформы, CRD, ServiceAccount, RBAC, конфигурации вебхуков и допуска, PriorityClass и класс хранилища во время approve. Платформенная identity исполнителя не может повышать привилегии, связывать роли или выдавать себя за других. Внутри пространства имен сервиса исполнитель может создавать только те Role, которые выдают уже имеющиеся у него разрешения.
• Никаких учетных данных для ваших бакетов или IAM. clicklink clctl executor prepare создает бакеты и сервисную роль, а clicklink clctl executor teardown удаляет их — обе команды выполняются под вашими учетными данными. Эту роль могут принять только поды соответствующего сервиса. Для прямого доступа к платформе исполнитель использует instance profile EC2-виртуальной машины коннектора, чтобы принять роль ECR puller только для чтения — как для входа при загрузке чарта, так и для проверок образов. Другие реестры чартов ECR используют окружающие учетные данные AWS; см. identities. Его единственные вызовы облачных API идут в ECR и STS; он не может читать или удалять ваши данные.
• Никаких сведений о пароле вашего пользователя default. clicklink clctl executor prepare генерирует его на вашей стороне и показывает один раз (либо это делает clicklink clctl instances create, если вы передаете входные данные флагами). Отправляются только его хеши, поэтому ни коннектор, ни ClickHouse Cloud не смогут его восстановить.
• Никаких входящих подключений. ClickHouse Cloud никогда не открывает соединение в вашу среду. Единственные командные каналы — два исходящих WebSocket-соединения. Средство диагностики отклоняет любую команду, если включенный вами сеанс поддержки не активен. Исполнитель принимает команды жизненного цикла только для тех сервисов, управление которыми вы поручили ClickHouse, и только в рамках указанных выше областей. Даже во время сеанса средство диагностики ограничено с обеих сторон. Запросы к ClickHouse ограничены списком разрешённых таблиц, который отклоняет query_log и text_log, поэтому доступ к ним никогда не выдается. Доступ к Kubernetes ограничен представлениями только для чтения и журналами подов, которые разрешают Role, ограниченные пространством имен.

​

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

• Включение управляемого режима. Исполнитель работает, а его grant в Kubernetes существует только после того, как вы включите управляемый режим на этапе init; grant применяется с правами администратора кластера. См. управляемые сервисы.
• Создание сервиса. clicklink clctl executor prepare выполняется с вашими учётными данными AWS и создаёт бакеты и роль IAM, а clicklink clctl instances create отправляет определение. Без обоих шагов ClickHouse Cloud не может создать сервис в вашем кластере. См. создание сервиса.
• Обновления платформы. Каждое обновление компонентов платформы применяется только после того, как вы выполните clicklink clctl platform approve именно для этого набора; выпускаемый при этом токен истекает через 2 часа и никогда не продлевается. См. обновления платформы.
• Очистка после удаления. Удаление сервиса удаляет только его ресурсы Kubernetes. Команда clicklink clctl executor teardown, запущенная с вашими учётными данными, удаляет роль IAM и — только при указании явных флагов — данные и резервные копии. См. удалить сервис.
• Сеансы поддержки. Интерактивное устранение неполадок возможно только в включённом вами сеансе: по умолчанию он ограничен 4 часами, максимум — 24 часами. Отключение действует немедленно. См. сеансы поддержки.
• Список разрешённых операторов. Каждый запрос к шлюзу должен содержать токен OIDC, подтверждённый адрес электронной почты которого указан в вашем списке разрешённых. Пустой список разрешённых означает запрет доступа. Вы управляете этим списком; см. руководство по настройке.
• Доступность шлюза. Шлюз сеанса отключён, пока вы его не включите, и доступен только через проброс порта, если вы не настроите Входной шлюз. На виртуальной машине каждый оператор должен закрепить отпечаток его самоподписанного сертификата либо проверить его с помощью набора CA, переданного через --gateway-ca, прежде чем команды сеанса смогут подключиться к нему.
• Исходящий сетевой трафик. При использовании CNI с принудительным применением политик ни один демон не достигнет конечной точки вашего коннектора, пока вы не укажете её CIDR в networkPolicy.allowEgressCIDRs. Исполнителю также нужны CIDR API-сервера Kubernetes (networkPolicy.apiserverCIDRs), которые init --managed определяет из VPC кластера. Если чарты платформы загружаются из Amazon ECR, добавьте также диапазоны ECR и STS.

​

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

• Идентичность развертывания. Common name клиентского сертификата mTLS — это ID вашей организации, а его единственное DNS-имя привязано к хосту вашей конечной точки. Благодаря этому каждое соединение с API можно отнести к вашей организации. Обновление выполняется автоматически внутри демона; ключевой материал не проходит через руки оператора.
• Целостность запроса. Каждый API request также несет подпись HMAC-SHA256 (Authorization: HMAC-SHA256 AccessKey=..., Signature=..., Timestamp=...), вычисленную по method, path, временной метке и hash тела с использованием пары ключей, выданной при enrollment.
• Идентичность оператора. Вызовы Gateway относятся к адресу электронной почты, подтвержденному OIDC ID token оператора и проверенному по JWKS вашего провайдера идентификации. Имени, указанному самим пользователем, доверия нет, если доступен token.
• Команды жизненного цикла. Исполнитель записывает каждую полученную команду в свое локальное хранилище вместе с ее origin (ClickHouse Cloud или локальный вызов clicklink clctl), стадией и результатом. Результат он сообщает обратно по командному каналу. Прочитать запись можно с помощью clicklink clctl commands list и clicklink clctl commands get; см. CLI reference.
• Одобрения платформы. Дайджест одобренного вами bundle записывается в ServiceAccount pcm-platform. Каждый object, примененный с вашими credentials, несет hash содержимого, который исполнитель проверяет перед любой записью. Bundle с любым другим дайджестом отклоняется.
• Журнал аудита. Каждая команда сеанса — принятая или заблокированная — добавляется в audit log в формате NDJSON вместе с идентичностью организации, полученной из командного канала. Вызовы Gateway записываются как structured строки clctl.gateway в log средства диагностики с подтвержденным адресом электронной почты оператора. При локальных изменениях сеанса на ВМ в session.json записывается пользователь хоста. Прочитать audit log можно с помощью clicklink clctl troubleshoot audit tail; см. CLI reference.

​

Значения по умолчанию для минимизации данных

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