Добрый вечер, на странице https://clickhouse.com/docs/en/guides/sre/keeper/clickhouse-keeper/ есть описание кластера, в котором

есть имя и пароль.

<shard>
<replica>
<host>chnode2.domain.com</host>
<port>9000</port>
<user>default</user>
<password>ClickHouse123!</password>

С пояснением "username that will be used to authenticate to the cluster instances"/"password for the user define to allow connections to cluster instances"
Зачем нужен этот пользователь?

https://docs.altinity.com/operationsguide/security/clickhouse-hardening-guide/user-hardening/#:~:text=User%20hardening%20security%20procedures.,by%20hostname%20or%20IP%20address

Прошу прощения, а можно ткнуть в конкретное место этого текста? Не нашел ничего, отвечающего на вопрос о смысле user и password в описании кластера.

сервера КХ друг про друга не знают, никакого кластера в КХ нету, все сервера абсолютно независимы. Кластер получается в момент запроса, когда Distributed таблица выполняет запрос, она подключается к другим нодам как обычный клиент, используя пользователь и пароль (или secret)

Да, ок, понятно, спасибо. Получается, что row level security и Distributed - разные миры, и либо одно, либо другое? Или RLS умеет поддерживать сама таблица Distributed? Ну и всякий там kerberos, LDAP и прочие умные слова, а вот здесь мы запишем пароль плэйнтекстом в конфиг?

это все перперндикулярные вещи, row level security будет работать, там init пользователь прокидывается в контексте запроса. row level security нельзя наложить на Distrbiuted но это совсем другой вопрос, это и не важно, оно будет работать на MergeTree (и гранты все тоже самое) >Ну и всякий там kerberos, LDAP и прочие умные слова, а вот здесь мы запишем пароль плэйнтекстом в конфиг? нене девид блейн, это про не хранение пароля на клиенте, а не про сервер, если ты сервере уже рут, то пароли плейтекстом уже мало что меняют ну есть варианты, можно использовать secret и тогда не нужен user/password, но secret тоже плейн-текстом, или можно использовать auth по ip, и ходить без пароля с сервера на сервер (default-м). Но все тоже самое, если ты на сервере рут, то ты уже в любом случае сможешь к другим серверам КХ ходить без паролей.

Я пропустил RLS, задам наивный вопрос. "Нельзя наложить RLS на Distributed", это by design, или "стремились катануть киллер-фичу, но что-то пошло не так, и сломалось об дистрибутед"?

Да, понял. Просто я решил, что в MergeTree или что-то, поверх чего сделан Distributed, будут обращаться от имени того самого пользователя, прописанного в конфиге кластера. Но это конечно же ерунда. Спасибо!

она работает в самом низу MergeTree, т.е. она работает, просто накладывается на MergeTree, а не на Distributed, никакой проблемы нет. есть хотелка у людей которые хотят настраивать все только на выделенном инициаторе, и накладывать гранты и полиси на Distributed, не делая ничего на дата-нодах, но это редкий юзкейз

Кажется логичным, что RLS работает там, где хранятся данные. Т.е. не на уровне самой Distributed

понял. стандартная тема для CH - каждая нода конфигурится по-своему, и можно создать конструкцию, где RLS на ноде 1 != RLS на ноде 2. Типа на ноде 1 сказано "этому парню давай читать только чётные строки", а на ноде 2 сказано "этому парню дай читать только строки с остатком от деления на 71 == 4". а потребность пользователя здорового человека - "дайте мне возможность консистентно управлять RLS для всего кластера из одного места/в рамках запроса"?

сейчас можно в зукипере хранить пользователей / права и управлять из одного места, только документации про это нету 🙂

"Security through obscurity"