Авторизация

Основные понятия

Авторизация в YDB основана на понятиях:

• Объект доступа
• Субъект доступа
• Права доступа
• Список доступов
• Владелец
• Пользователь
• Группа

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

Авторизация выполняется на каждое действие пользователя: его права не кешируются, так как могут быть отозваны или предоставлены в любой момент времени.

Пользователь

Пользователи в YDB могут создаваться в разных источниках:

• локальные пользователи в базах данных YDB;
• внешние пользователи из сторонних служб доступа к каталогам.

Для создания, изменения и удаления локальных пользователей YDB есть команды:

• CREATE USER
• ALTER USER
• DROP USER

SID

YDB позволяет работать с пользователями из разных каталогов и систем, и они отличаются SID с использованием суффикса.

Суффикс @<auth-domain> идентифицирует «источник пользователя», внутри которого гарантируется уникальность всех логинов или идентификаторов пользователей. Например, в случае аутентификации LDAP SID'ы пользователей будут user1@ldap и user2@ldap.

У локальных пользователей пустой auth-domain. Если SID пользователя не содержит суффикса, то имеется в виду локальный пользователь, созданный и существующий непосредственно в кластере YDB.

Группа

Любого пользователя можно включить в ту или иную группу доступа или исключить из неё. Как только пользователь включается в группу, он получает все права на объекты базы данных, которые предоставлялись группе доступа.
С помощью групп доступа YDB можно реализовать бизнес-роли пользовательских приложений, заранее настроив требуемые права доступа на нужные объекты.

Для создания, изменения и удаления групп есть следующие виды YQL запросов:

• CREATE GROUP
• ALTER GROUP
• DROP GROUP

Права доступа

Права доступа в YDB привязаны не к субъекту, а к объекту доступа.

У каждого объекта доступа есть список прав — ACL (Access Control List) — он хранит все предоставленные субъектам доступа (пользователям и группам) права на объект.

По умолчанию, права наследуются от родителей потомкам по дереву объектов доступа.

Для управления правами служат следующие виды YQL запросов:

• GRANT.
• REVOKE.

Для управления правами служат следующие CLI-команды:

• chown
• grant
• revoke
• set
• clear
• clear-inheritance
• set-inheritance

Для просмотра ACL объекта доступа служат следующие CLI-команды:

• describe
• list

Владелец объекта

У каждого объекта доступа есть владелец. Им по умолчанию становится субъект доступа, создавший объект доступа.

Владелец объекта есть в том числе у кластера в целом и каждой базы данных.

Сменить владельца можно с помощью CLI команды chown.

Просматривать владельца объекта можно с помощью CLI команды describe.

Списки уровней доступа

В дополнение к спискам прав, управляющим доступом к конкретным схемным объектам, YDB использует списки уровней доступа для определения иерархических уровней доступа к общекластерным операциям.

Для операций, в которых одновременно проверяются списки прав и списки уровней доступа, оба механизма применяются совместно: действие доступно только если обе проверки его разрешают, и недоступно, если хотя бы одна проверка не пройдена. Для остальных операций применяется только соответствующий механизм проверки.

Иерархия уровней доступа

Списки уровней доступа образуют иерархию, которая используется в Embedded UI, viewer и во многих других общекластерных действиях (порядок от меньших привилегий к большим):

• database_allowed_sids (Database) - доступ к операциям в контексте конкретной базы;
• viewer_allowed_sids (Viewer) - доступ к просмотру общекластерного состояния;
• monitoring_allowed_sids (Monitoring) - доступ к операционным действиям в Embedded UI;
• administration_allowed_sids (Administration) - административные действия с кластером и базами.

Более высокий уровень автоматически включает все более низкие, поэтому субъекту достаточно присутствовать только в одном списке. Например, наличие в administration_allowed_sids автоматически даёт привилегии monitoring, viewer и database.
Подробности по каждому уровню — в разделе Описание уровней доступа.

Дополнительно существуют два отдельных списка уровней доступа для специфических операций:

• bootstrap_allowed_sids — разрешает операции начальной инициализации кластера;
• register_dynamic_node_allowed_sids — разрешает регистрацию узлов в кластере.

Описание уровней доступа

Списки уровней доступа настраиваются в конфигурации безопасности и определяют привилегии для:

• Database (наличие в database_allowed_sids) — доступ только в контексте конкретной базы данных. Можно открыть Embedded UI и работать с данными этой базы, но нельзя выполнять общекластерные запросы (например, просматривать список узлов кластера). Запросы без указания базы запрещены.
• Viewer (наличие в viewer_allowed_sids) — доступ только на чтение для общекластерного состояния: можно просматривать страницы Embedded UI и диагностическую информацию, но нельзя запускать действия, изменяющие состояние системы.
• Monitoring (наличие в monitoring_allowed_sids) — доступ к операционным действиям в Embedded UI, включая действия, которые могут менять состояние системы. Например, запуск резервного копирования, восстановление базы или выполнение YQL-запросов через Embedded UI.
• Administration (наличие в administration_allowed_sids) — даёт право выполнять административные действия с базами данных или кластером. Полный административный доступ к кластеру и его базам данных. Также используется для изменения конфигурации, схемных операций, требующих административных прав, и других административных проверок.
• Register node (наличие в register_dynamic_node_allowed_sids) — отдельный (неиерархический) уровень для регистрации динамических узлов в кластере. Не даёт автоматически прав database/viewer/monitoring/administration. По техническим причинам, если список задан (не пуст), он должен включать root@builtin.
• Bootstrap (наличие в bootstrap_allowed_sids) — отдельный (неиерархический) уровень только для операций начальной инициализации кластера. Используется в неинициализированном состоянии, когда подсистема аутентификации ещё не функционирует. Начальная инициализация разрешена, если субъект входит в bootstrap_allowed_sids или administration_allowed_sids, при этом сам по себе bootstrap не выдаёт полные административные привилегии.