- SQL-команд. Для этого нужно включить эту возможность.
-
файлов конфигурации сервера
users.xmlиconfig.xml.
Нельзя одновременно управлять одним и тем же объектом управления доступом обоими методами конфигурации.
Если вы хотите управлять пользователями консоли ClickHouse Cloud, обратитесь к этой странице
SHOW ACCESS.
Обзор
По умолчанию сервер ClickHouse предоставляет учётную записьdefault, для которой нельзя использовать систему управления доступом и учётными записями на основе SQL, но при этом у неё есть все права и разрешения. Учётная запись default используется во всех случаях, когда имя пользователя не указано, например при входе из клиента или в распределённых запросах. При обработке распределённых запросов учётная запись default используется, если в конфигурации сервера или кластера не указаны свойства user and password.
Если вы только начали использовать ClickHouse, рассмотрите следующий сценарий:
- Включите систему управления доступом и учётными записями на основе SQL для пользователя
default. - Войдите в учётную запись
defaultи создайте всех необходимых пользователей. Не забудьте создать учётную запись администратора (GRANT ALL ON *.* TO admin_user_account WITH GRANT OPTION). - Ограничьте разрешения для пользователя
defaultи отключите для него систему управления доступом и учётными записями на основе SQL.
Свойства текущего решения
- Вы можете выдавать разрешения на базы данных и таблицы, даже если они не существуют.
- Если таблица удалена, все привилегии, связанные с этой таблицей, не отзываются. Это означает, что даже если позже вы создадите новую таблицу с тем же именем, все привилегии останутся действительными. Чтобы отозвать привилегии, связанные с удалённой таблицей, нужно выполнить, например, запрос
REVOKE ALL PRIVILEGES ON db.table FROM ALL. - Для привилегий нет настроек времени действия.
Учетная запись пользователя
Учетная запись пользователя — это объект управления доступом, который позволяет аутентифицировать пользователя в ClickHouse. Учетная запись пользователя содержит:- Идентификационную информацию.
- Привилегии, которые определяют, какие запросы пользователь может выполнять.
- Хосты, которым разрешено подключаться к серверу ClickHouse.
- Назначенные роли и роли по умолчанию.
- Настройки с их ограничениями, которые по умолчанию применяются при входе пользователя в систему.
- Назначенные профили настроек.
Применение настроек
Настройки можно задавать на разных уровнях: для учетной записи пользователя, в назначенных ей ролях и в профилях настроек. При входе пользователя в систему, если настройка задана для разных объектов управления доступом, ее значение и constraints применяются следующим образом (от более высокого приоритета к более низкому):- Настройки учетной записи пользователя.
- Настройки ролей по умолчанию для учетной записи пользователя. Если настройка задана в нескольких ролях, порядок ее применения не определен.
- Настройки из профилей настроек, назначенных пользователю или его ролям по умолчанию. Если настройка задана в нескольких профилях, порядок ее применения не определен.
- Настройки, применяемые ко всему server по умолчанию или из профиля по умолчанию.
Роль
Роль — это контейнер для сущностей доступа, которые можно предоставить учётной записи пользователя. Роль содержит:- Привилегии
- Настройки и ограничения
- Список назначенных ролей
ROW POLICY
ROW POLICY — это фильтр, определяющий, какие строки доступны пользователю или роли. ROW POLICY содержит фильтры для одной конкретной таблицы, а также список ролей и/или пользователей, к которым должна применяться эта ROW POLICY. ROW POLICY применяется, когда данные таблицы читаются локально. Для таблицы Distributed или другой таблицы, делегирующей чтение удалённым серверам, определите политику для базовых таблиц на каждом сервере: политику для самой таблицы, обращающейся к удалённым данным, нельзя применить к отправленному запросу, поэтому операции чтения через неё отклоняются. Такая политика для базовой таблицы не применяется, если инициатор отправляет уже сформированный план чтения, поэтому для пользователей, чьи ROW POLICY должны соблюдаться, оставьтеserialize_query_plan = 0 (см. issue #112891).
ROW POLICY имеет смысл только при доступе только для чтения. Если вы можете изменять таблицу или копировать партиции между таблицами, это сводит на нет ограничения ROW POLICY.
Профиль настроек
Профиль настроек — это набор настроек. Профиль настроек содержит настройки и ограничения, а также список ролей и/или пользователей, для которых применяется этот профиль. Команды управления:- CREATE SETTINGS PROFILE
- ALTER SETTINGS PROFILE
- DROP SETTINGS PROFILE
- SHOW CREATE SETTINGS PROFILE
- SHOW PROFILES
Квота
Квота ограничивает использование ресурсов. См. Квоты. Квота содержит набор ограничений для определённых интервалов времени, а также список ролей и/или пользователей, к которым применяется эта квота. Команды управления:Включение системы управления доступом и учётными записями на основе SQL
- Настройте каталог для хранения конфигурации. ClickHouse хранит конфигурации объектов управления доступом в каталоге, заданном параметром конфигурации сервера access_control_path.
-
Включите систему управления доступом и учётными записями на основе SQL как минимум для одной учётной записи пользователя.
Файл конфигурации
users.xml, поставляемый вместе с ClickHouse, включает систему управления доступом и учётными записями на основе SQL для пользователяdefault, устанавливая значение 1 для настроекaccess_managementиnamed_collection_control. Для всех остальных пользователей обе настройки по умолчанию имеют значение 0, поэтому их необходимо задавать явно. Настройкаshow_named_collections_secretsпо умолчанию имеет значение 0 даже для пользователяdefault, поскольку возможность управлять named collection не означает возможности прочитать уже сохранённые в них учётные данные. Пользователь может предоставлять только те привилегии, которыми обладает сам, поэтому, пока эта настройка равна 0, пользователь не имеет полного набора привилегий, и запрос видаGRANT ALL ON *.* TO clickhouse_admin WITH GRANT OPTIONбудет отклонён:Установите все три настройки в 1, чтобы сделать пользователя полноценным администратором.
Определение SQL-пользователей и ролей
В этой статье рассматриваются основы определения SQL-пользователей и ролей, а также применения этих привилегий и разрешений к базам данных, таблицам, строкам и столбцам.Включение режима SQL-пользователей
-
Включите режим SQL-пользователей в файле
users.xmlв секции пользователя<default>:Первые две настройки уже включены для пользователяdefaultв файлеusers.xml, который поставляется вместе с ClickHouse; параметрshow_named_collections_secretsтам закомментирован, и его необходимо раскомментировать.
Пользователь
default — единственный пользователь, который создается при новой установке, и именно эта учетная запись по умолчанию используется для межузлового взаимодействия.В рабочей среде рекомендуется отключить этого пользователя после того, как межузловое взаимодействие будет настроено с SQL-пользователем с правами администратора, а также будут настроены <secret>, учетные данные кластера и/или учетные данные HTTP и транспортного протокола для межузлового взаимодействия, поскольку учетная запись default используется для межузлового взаимодействия.- Перезапустите узлы, чтобы применить изменения.
-
Запустите клиент ClickHouse:
Создание пользователей
- Создайте учетную запись администратора SQL:
- Предоставьте новому пользователю полные административные права
Разрешения ALTER
Эта статья поможет вам лучше понять, как задавать разрешения и как они работают при использовании командALTER привилегированными пользователями.
Команды ALTER делятся на несколько категорий: некоторые из них иерархические, а некоторые — нет и должны быть явно определены.
Пример конфигурации DB, таблицы и пользователя
- Используя пользователя с ролью Admin, создайте тестового пользователя
- Создайте тестовую базу данных
- Создайте тестовую таблицу
- Создайте тестового пользователя с правами администратора для назначения/отзыва привилегий
Чтобы выдавать или отзывать разрешения, пользователь admin должен иметь привилегию Чтобы выдавать (
WITH GRANT OPTION.
Например:GRANT) или отзывать (REVOKE) привилегии, пользователь должен сначала сам иметь эти привилегии.ALTER:
- Предоставление привилегий
ALTERпользователю или роли
GRANT ALTER on *.* TO my_user влияет только на ALTER TABLE и ALTER VIEW верхнего уровня; остальные команды ALTER нужно выдавать или отзывать по отдельности.
например, предоставление базовой привилегии ALTER:
ALTER TABLE и ALTER VIEW, показанные в примере выше, однако не предоставит некоторые другие разрешения ALTER, такие как ALTER ROW POLICY (вернитесь к иерархии, и вы увидите, что ALTER ROW POLICY не является дочерним элементом ALTER TABLE или ALTER VIEW). Их нужно явно предоставить или отозвать.
Если требуется только часть разрешений ALTER, каждое из них можно предоставить отдельно; если у такого разрешения есть подпривилегии, они тоже будут предоставлены автоматически.
Например:
- Отзыв привилегий
ALTERу пользователей и ролей
REVOKE работает аналогично оператору GRANT.
Если пользователю/роли была выдана дочерняя привилегия, вы можете либо отозвать её напрямую, либо отозвать вышестоящую привилегию, от которой она наследуется.
Например, если пользователю был предоставлен grant ALTER ADD COLUMN
WITH GRANT OPTION, но и сам располагает этими привилегиями.
- Чтобы предоставить пользователю-администратору эту привилегию, а также разрешить ему управлять набором привилегий Ниже приведён пример:
ALTER COLUMN и все дочерние привилегии.
Тестирование
- Добавьте право
SELECT
- Добавьте пользователю привилегию добавления столбца
- Войдите под пользователем с ограниченными правами
- Проверка добавления столбца
- Проверка удаления столбца
- Проверка привилегии alter admin путем выдачи права
- Войдите под пользователем alter admin
- Предоставить подпривилегию
- Проверьте выдачу привилегии, которой нет у пользователя alter admin и которая не входит в число подпривилегий привилегий пользователя admin.
ALTER образуют иерархию для операций ALTER над таблицами и представлениями, но не для других операторов ALTER. Разрешения можно задавать как на детальном уровне, так и через их группировку, и аналогичным образом отзывать. Пользователь, который выдает или отзывает привилегии, должен иметь WITH GRANT OPTION, чтобы назначать привилегии пользователям, включая самого себя, и уже должен обладать соответствующей привилегией. Действующий пользователь не может отозвать собственные привилегии, если у него самого нет привилегии GRANT OPTION.