3 
ClickHouse давно требует гибкого подхода к управлению доступом, особенно когда в компании растёт число пользователей и сервисов. Раньше администраторам приходилось либо вести учётные записи вручную, либо полагаться на LDAP. Теперь появилась возможность подключить внешний провайдер идентификации и работать с короткоживущими токенами. Это меняет привычную картину и снижает риски, связанные с общими паролями. Токен здесь выступает как временный цифровой ключ, который подтверждает личность пользователя или сервиса без передачи постоянного пароля. Shared-аккаунты, напротив, представляют собой общие учётные записи, которые используют несколько человек или приложений одновременно, что усложняет отслеживание действий.
Зачем командам в РФ
В условиях импортозамещения многие организации ищут способы отказаться от проприетарных систем аутентификации. Команды хотят сохранить централизованное управление, но без лишних зависимостей от внешних вендоров. Antalya даёт такой вариант на базе открытого кода и позволяет интегрировать ClickHouse с уже имеющимися в компании решениями.
При этом отпадает необходимость заводить отдельные учётные записи для каждого сервиса. Группы и роли можно описывать один раз во внешнем провайдере, а ClickHouse будет применять к ним свои правила RBAC. RBAC означает управление доступом на основе ролей: администратор определяет роли с набором прав, а затем назначает эти роли пользователям или группам. В итоге упрощается аудит и снижается вероятность ошибок при ротации паролей. Аудит в данном контексте — это процесс записи и анализа всех действий в базе, чтобы позже понять, кто и что делал.
Кроме того, короткоживущие токены позволяют быстрее реагировать на инциденты. Если токен попал в чужие руки, его срок действия истекает автоматически через заданное время. Это заметно безопаснее, чем хранить постоянные пароли в конфигурационных файлах или скриптах. Скрипты здесь — это небольшие программы или команды, которые выполняют регулярные задачи, например, загрузку данных.
Что изменилось
Раньше в open-source версии ClickHouse было два основных способа работы с пользователями: правка конфигурационных файлов или использование LDAP-сервера. Оба подхода часто приводили к появлению общих сервисных аккаунтов, которые передавали между командами. В результате сложно было понять, кто именно выполнял запрос, и затруднялась ротация учётных данных. Ротация — это регулярная смена паролей или ключей для снижения риска их компрометации.
С поддержкой OAuth и OIDC в сборке Antalya пользователи определяются во внешнем identity provider. OAuth — это стандарт, который позволяет приложениям получать доступ к ресурсам от имени пользователя без передачи его пароля. OIDC — это надстройка над OAuth, которая добавляет возможность подтверждения личности через токены. ClickHouse получает от него токен, проверяет его и применяет существующие правила RBAC. При этом не требуется создавать отдельную запись для каждого человека в самой базе.
Аудит теперь строится на информации из токена, а не только на имени пользователя из конфига. Это позволяет видеть, какая группа и какой клиент инициировали действие. Такой подход сохраняет всю мощь встроенных механизмов ClickHouse, но переносит управление идентичностью за пределы кластера. Идентичность здесь означает набор данных о пользователе или сервисе, включая его группы и права.
Практика по шагам
Сначала нужно развернуть identity provider, например Keycloak или Authentik, внутри своей инфраструктуры. После установки провайдера создают realm или tenant, регистрируют клиента для ClickHouse и настраивают выдачу access-токенов с нужными scope. Realm или tenant — это изолированная область внутри провайдера, где хранятся настройки пользователей, групп и клиентов. Важно указать алгоритм подписи токенов и срок их жизни, чтобы они не оставались действительными слишком долго. На этом этапе распространённая ошибка — неправильный выбор scope: если не включить необходимые разрешения, токен не будет содержать нужных claims, и доступ к ClickHouse окажется заблокирован. Claims — это отдельные утверждения внутри токена, например, имя пользователя или список групп.
Далее в конфигурации Antalya указывают адрес провайдера и параметры проверки токенов. В файле настроек прописывают endpoint для получения ключей и правила маппинга claims из токена на роли ClickHouse. Endpoint — это конкретный адрес, по которому ClickHouse может запросить публичные ключи для проверки подписи токена. Маппинг означает сопоставление: значение из токена, например группа «analysts», преобразуется в роль внутри ClickHouse. После перезапуска сервера проверяют, что кластер принимает токен и не требует пароль. Здесь важно протестировать не только успешный вход, но и случай с неверным токеном, чтобы убедиться в отказе доступа. Подводный камень — несоответствие алгоритма подписи между провайдером и Antalya, из-за чего проверка токена всегда завершается ошибкой.
Затем в самом ClickHouse создают роли и политики доступа, привязывая их к группам из identity provider. Проверяют работу через тестовый клиент: получают токен, отправляют запрос и смотрят в логах, какая роль применилась. Если всё настроено верно, запрос выполняется с нужными ограничениями, а в аудите остаётся запись о токене. Политики доступа — это дополнительные правила, которые ограничивают, какие таблицы или столбцы доступны роли. На этом шаге часто возникает проблема: если маппинг claims настроен слишком широко, пользователь получает больше прав, чем предполагалось. Поэтому рекомендуется сначала создать тестовую группу с минимальными правами и проверить, что доступ действительно ограничен.
Отличие от прежнего подхода заметно сразу. Раньше приходилось вручную добавлять каждого пользователя в конфиг или LDAP и следить за синхронизацией. Теперь изменения групп происходят только в identity provider, а ClickHouse подхватывает их автоматически при следующем запросе. Это сокращает количество ручных правок и уменьшает риск расхождений между системами.
Дополнительно стоит настроить refresh-токены, чтобы клиент мог обновлять access-токен без повторной аутентификации. Проверяют, что refresh-токен не передаётся на сервер ClickHouse, а остаётся только у клиента. Это соответствует стандарту OAuth и снижает поверхность атаки. Refresh-токен — это отдельный ключ, который позволяет получить новый access-токен по истечении срока старого. Ошибка здесь может привести к тому, что refresh-токен случайно попадёт в логи или конфиг, что создаёт дополнительный риск.
Ограничения self-host
При самостоятельном развёртывании identity provider приходится самостоятельно обеспечивать его отказоустойчивость и резервное копирование. Если провайдер недоступен, пользователи не смогут получить токены и подключиться к ClickHouse. Это требует дополнительных ресурсов на мониторинг и обновление самого identity provider. Мониторинг означает постоянное отслеживание доступности и производительности сервиса.
Кроме того, настройка правил маппинга claims и ролей занимает время. Нужно точно понимать, какие поля токена будут использоваться и как они соотносятся с объектами ClickHouse. Ошибка в конфигурации может привести к избыточным правам или, наоборот, к отказу в доступе. Избыточные права означают, что пользователь получает доступ к данным, которые ему не нужны, что повышает риск утечки.
Self-host также означает, что вся ответственность за безопасность провайдера лежит на команде. Нужно регулярно обновлять компоненты, следить за уязвимостями и настраивать ограничения доступа к административному интерфейсу. В отличие от внешних сервисов, здесь нет готовой поддержки со стороны вендора. Административный интерфейс — это веб-страница, через которую настраивают пользователей и клиентов, поэтому к нему нужен особенно строгий контроль доступа.
Источник
Оригинал: Altinity — OAuth и Antalya: токены вместо shared-аккаунтов в ClickHouse
