--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ytsaurus.tech/docs/en/user-guide/storage/access-control.md - https://ytsaurus.tech/docs/ru/user-guide/storage/access-control.md --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt # Общие сведения В данном разделе собрана информация о системе контроля доступа к таблицам и другим узлам [Кипариса](https://ytsaurus.tech/docs/ru/user-guide/storage/cypress.md) (пользователям, группам, аккаунтам, чанкам, транзакциям и т. д.). Любой пользовательский запрос проходит через прокси, которые [**аутентифицируют**](https://ru.wikipedia.org/wiki/Authentication) пользователя, то есть проверяют его подлинность. На основе содержащегося в запросе токена, полученного с помощью протокола [OAuth](https://ru.wikipedia.org/wiki/OAuth), прокси определяет имя пользователя, инициировавшего запрос. Если токен в запросе не указан, то считается, что запрос задан от пользователя `guest`. После прохождения аутентификации, на последующих этапах обработки пользовательского запроса токен не используется. Подробнее о токенах можно прочитать в разделе [Аутентификация](https://ytsaurus.tech/docs/ru/user-guide/storage/auth.md). **Авторизацией** (выдачей разрешений) занимается мастер-сервер Кипариса. Решение о предоставлении или отказе в доступе зависит от: 1. Вида доступа (чтение, запись и т.д.); 2. Пользователя, инициировавшего запрос; 3. Объекта, к которому запрашивается доступ. В случае отказа в праве доступа формируется сообщение в котором указаны детали: имя пользователя, которому отказано в доступе, объект, к которому запрашивался доступ, и тип доступа. Если от прокси приходит запрос, помеченный именем несуществующего пользователя, то мастер-сервер вернёт ошибку `No such user`. Такая ситуация потенциально возможна, поскольку получение токена и регистрация пользователя в системе — два действия, выполняемые на различных сервисах (получение токена происходит с помощью сервиса OAuth, а регистрация — на мастер-сервере YTsaurus). В системе YTsaurus поддерживаются списки **пользователей** и **групп**. Обобщенно пользователи и группы называются **субъектами**. Членами групп могут быть произвольные субъекты: как пользователи, так и другие группы. Система гарантирует, что отношение «вхождение в группу» не содержит циклов. При авторизации решения принимаются на основе транзитивного замыкания. Таким образом, пользователь `A` может быть членом группы `C` как напрямую (входить непосредственно в состав группы `С`), так и косвенно (`A` входит в группу `B`, а группа `B` — в группу `C`). У каждого объекта в системе YTsaurus существует список контроля доступа (**Access Control List** или **ACL**). Данный список хранится в атрибуте `@acl` объекта и состоит из отдельных записей (**Access Control Entry** или **ACE**), где каждая запись содержит перечень субъектов, тип доступа и ряд других параметров, приведённых в таблице раздела [Авторизация](https://ytsaurus.tech/docs/ru/user-guide/storage/access-control.md#authorization). Подробнее читайте в секции [Как правильно использовать ACL](#acl_usage). ## Пользователи, группы { #users_groups } В Кипарисе хранятся: * Список всех зарегистрированных пользователей. Список хранится по адресу `//sys/users` и представляет собой узел типа `user_map`. * Список всех зарегистрированных групп. Хранится по адресу `//sys/groups` и представляет собой узел типа `group_map`. {% note warning "Внимание" %} Каждый пользователь и группа определяется уникальным именем. При этом пользователи и группы располагаются в одном пространстве имён, то есть имена пользователей и групп не могут совпадать. {% endnote %} #### Как посмотреть списки пользователей и групп {% list tabs %} - Через веб-интерфейс - Чтобы просмотреть список пользователей, на боковой панели перейдите в раздел **Users** или введите в адресной строке браузера: `https:////users` - Чтобы просмотреть список групп, перейдите в раздел **Groups** или введите в адресной строке браузера: `https:////groups` - Через CLI - Получить список пользователей: ```bash yt --proxy list //sys/users ``` - Получить список групп: ```bash yt --proxy list //sys/groups ``` {% endlist %} {% note warning %} Узлы `//sys/users` и `//sys/groups` не являются таблицами, поэтому списки пользователей и групп нельзя получить с помощью `SELECT` запроса. {% endnote %} Пользователи имеют тип системного объекта `user`. Группы имеют тип объекта `group`. #### Как получить информацию о пользователе или группе {% list tabs %} - Через веб-интерфейс Перейдите на страницу пользователя или группы и нажмите значок ![](../../../images/attrs-icon.png =20x20) справа. - Через CLI Чтобы получить сведения о конкретном пользователе, используйте команду `yt --proxy get //sys/users//@`. Например: ``` $ yt --proxy get //sys/users/vasya/@type "user" ``` Посмотреть список всех доступных атрибутов у пользователя можно командой: ```bash $ yt --proxy get //sys/users/vasya/@ { "id" = "ffffffff-fffffffe-101f5-1407420e"; "type" = "user"; "builtin" = %true; ... } ``` Аналогично, чтобы получить сведения о конкретной группе, используйте команду `yt --proxy get //sys/groups//@`. Например: ```bash $ yt --proxy get //sys/groups/admins/@type "group" ``` {% endlist %} ## Системные субъекты { #system_subjects } В системе YTsaurus присутствует набор субъектов, выполняющих системные функции. Таких субъектов нельзя удалить. К системным субъектам относятся: 1. Пользователи `guest`, `root`, `scheduler` и `job`; 2. Группы `everyone`, `users`, `superusers`. ## Атрибуты субъектов { #subject_attributes } В таблице ниже представлен список атрибутов, которые имеются у всех субъектов. | **Атрибут** | **Тип** | **Описание** | | ------------------- | --------------- | ------------------------------------------------------------ | | `name` | `string` | Имя субъекта (непустая строка) | | `member_of` | `array` | Список имен групп, которым непосредственно принадлежит данный субъект | | `member_of_closure` | `array` | Список имен групп, которым принадлежит субъект (прямо или косвенно) | | `aliases` | `array` | Список имен, которые могут использоваться в ACL в качестве ссылки на данный субъект | ## Атрибуты пользователей { #user_attributes } Помимо атрибутов, присущих всем субъектам, пользователи имеют атрибуты, представленные в таблице ниже. | **Атрибут** | **Тип** | **Описание** | **Обязательный** | | -------------------------- | --------------- | ------------------------------------------------------------ | ------------------- | | `banned` | `bool` | Заблокирован ли пользователь | Нет | | `access_time` | `DateTime` | Время последнего запроса от пользователя. | Да | | `access_counter` | `integer` | Общее число запросов, заданных пользователем. | Да | | `request_rate` | `double` | Количество запросов в секунду от пользователя. | Да | | `request_rate_limit` | `double` | Ограничение на количество запросов в секунду от пользователя. По умолчанию 100. | Да | | `request_queue_size_limit` | `double` | Длина очереди запросов. По умолчанию 100. | Да | | `usable_accounts` | `array` | Список аккаунтов, которые пользователю разрешено использовать. | Да | ## Атрибуты групп { #group_attributes } Помимо атрибутов, присущих всем субъектам, группы имеют атрибуты, представленные в таблице ниже. | **Атрибут** | **Тип** | **Описание** | | ----------- | --------------- | --------------------------------------------------------- | | `members` | `array` | Список имен членов группы (пользователей и других групп). | ## Управление группами { #group_control } {% note info "Примечание" %} На больших кластерах управление группами напрямую доступно только администраторам YTsaurus. {% endnote %} Чтобы создать новую группу, используется команда `create`. При создании не нужно указывать путь объекта, но требуется указать атрибут `name`. ```bash yt create group --attributes '{name=my_group}' ``` Удаляются группы командой `remove`. При удалении группа автоматически удаляется из всех ACL, где она участвовала. ```bash yt remove //sys/groups/my_group ``` ## Авторизация { #authorization } Модуль авторизации на мастер-сервере решает следующую задачу: разрешить ли пользователю `U` доступ типа `P` для объекта `O`? Вариантов ответа может быть два: разрешить или не разрешать. Разберем все три компонента (U, P и O) по-отдельности. В качестве `U` может выступать любой пользователь системы. Отметим, что `U` не может быть группой, хотя членство в группах учитывается при принятии решения. Если `U` — это `root`, то запрос доступа автоматически удовлетворяется. Тип доступа `P` иначе также называется **правом** (permission). Права, которые поддерживаются системой YTsaurus представлены в таблице. В столбце **Применяется к** перечислены типы объектов, для которых право имеет смысл; для остальных типов объектов право игнорируется. | Право | Применяется к | Описание | | ------------------------- | ------------------------------------------------- | ------------------------------------------------------------ | | `read` | Все объекты | Чтение значения или получение информации об объекте и его атрибутах. См. [подробнее](#permission_read). | | `full_read` | Таблицы (для остальных объектов работает как `read`) | Чтение всей таблицы без ограничений на уровне колонок и строк. См. [подробнее](#permission_full_read). | | `write` | Все объекты | Изменение состояния объекта или его атрибутов. | | `use` | Аккаунты, пулы, бандлы | Использование ресурсов объекта. См. [подробнее](#permission_use). | | `administer` | Все объекты | Изменение дескриптора доступа объекта (его ACL и связанных атрибутов). | | `create` | Схемы объектов | Создание объектов соответствующего типа. | | `remove` | Все объекты | Удаление объекта. | | `mount` | Динамические таблицы | Монтирование, размонтирование, перемонтирование, заморозка, разморозка и решардирование динамической таблицы. | | `manage` | Операции | Управление операцией и её джобами. См. [Управление операциями](#managing-operations). | | `modify_children` | Составные узлы Кипариса, аккаунты, пулы | Добавление и удаление детей составного объекта. См. [подробнее](#permission_modify_children). | | `register_queue_consumer` | Очереди | Регистрация консьюмера очереди. См. [подробнее](#permission_register_queue_consumer). | Объект `O` означает произвольный объект системы: узел Кипариса, пользователя, группу, аккаунт, чанк, транзакцию и так далее. Чтобы принять решение, система неявно строит **эффективный список управления доступом** (effective ACL) для объекта `O`. Эффективный список управления доступом — это объединение указанного на узле списка управления доступом и списков управления доступами, унаследованных от родителей. Любой **список управления доступом** (ACL) представляет собой список **записей управления доступом** (ACE). Порядок записей в этом списке не играет роли. Объект может наследовать свой ACL, за это отвечает атрибут `inherit_acl = %true`. При наследовании для каждой ACE определяется режим наследования (ключ `inheritance_mode` в записи `acl`). Последний может быть равен `object_only`, `object_and_descendants`, `descendants_only` и `immediate_descendants_only`. Значение `object_only` означает, что данная запись влияет только на сам объект. При значении `object_and_descendants` — на объект и всех его потомков, включая непрямых. При значении `descendants_only` — только на потомков, включая непрямых. При значении `immediate_descendants_only` — только на прямых потомков (сыновей). Каждая запись имеет структуру представленную в таблице. | **Атрибут** | **Тип** | **Описание** | | ------------------ | ------------------- | ------------------------------------------------------------ | | `action` | `SecurityAction` | Либо `allow` (разрешающая запись), либо `deny` (запрещающая запись). | | `subjects` | `array` | Список имен субъектов, на которые распространяется запись. | | `permissions` | `array` | Список прав доступа, на которые распространяется действие, указанное в атрибуте `action`. | | `inheritance_mode` | `InheritanceMode` | Режим наследования данной ACE, по умолчанию `object_and_descendants`. | Как только эффективный список построен, решение о предоставлении или непредоставлении доступа принимается по следующей схеме: 1. Если в списке есть хотя бы одна разрешающая запись для `U` и `P` и нет ни одной запрещающей записи для `U` и `P`, то доступ выдается. 2. Иначе доступ запрещается. «Запись для `U` и `P`» означает, что `P` упомянуто в списке `permissions`, а пользователь `U` (либо хотя бы одна группа, в которой он числится прямо или косвенно) — в списке `subjects`. Из представленного описания в частности следует, что если эффективный список пуст, то доступ будет запрещен. ### read { #permission_read } Для таблиц право `read` даёт доступ к данным, однако видимый набор колонок и строк может быть дополнительно сужен [колоночными ACL](https://ytsaurus.tech/docs/ru/user-guide/storage/columnar-acl.md) и [построчным доступом](https://ytsaurus.tech/docs/ru/user-guide/storage/row-level-security.md): даже имея право `read` на всю таблицу, пользователь должен быть явно допущен к чтению конкретных колонок или строк. ### full_read { #permission_full_read } Даёт неограниченный доступ на чтение всей таблицы, игнорируя любые ограничения на уровне колонок и строк. Для всех остальных типов объектов право `full_read` эквивалентно `read`. Оно требуется для действий, которым нужны данные целиком, например для выполнения команд `copy` или `move`. Поскольку это право подразумевает доступ ко всем колонкам, атрибут `columns` нельзя указывать в том же ACE. ### use { #permission_use } Даёт возможность использовать ресурсы объекта: * для аккаунта — создавать новые объекты в квоте этого аккаунта; * для пула — запускать операции в этом пуле; * для бандла — создавать динамические таблицы в этом бандле. ### modify_children { #permission_modify_children } Даёт возможность добавлять и удалять детей составного объекта. Для map-узла Кипариса создание или удаление ребёнка требует наличия права `write` или `modify_children` на родителе; выдача только `modify_children` позволяет субъекту управлять детьми узла, не предоставляя более широкого права `write` на сам узел. ### register_queue_consumer { #permission_register_queue_consumer } Даёт возможность [зарегистрировать консьюмера очереди](https://ytsaurus.tech/docs/ru/user-guide/dynamic-tables/queues.md#register_queue_consumer). ACE с этим правом имеет два особых правила: в нём должна быть указана витальность через атрибут `vital` (`%true` или `%false`), и оно должно содержать `register_queue_consumer` как единственное право. Например: ```bash { action = allow; subjects = [my_group]; permissions = [register_queue_consumer]; vital = %true; } ``` ## Владелец объекта и пользователь owner { #owner} При создании объекта пользователем `U`, он также становится владельцем данного объекта, что находит отражение в атрибуте `owner`. {% note info "Примечание" %} Изменить владельца может лишь суперпользователь (член группы `superusers`). {% endnote %} Также в системе есть специальный фиктивный пользователь `owner`. Им невозможно аутентифицироваться, однако на него можно ссылаться в ACL в качестве субъекта. При этом в момент проверки прав `owner` заменяется на фактического владельца объекта. Это позволяет, например, описать ограничение «в данном каталоге удалять узлы могут только те, кто их создал» таким ACE:`{action=allow; permissions=[remove]; subjects=[owner]; inheritance_mode = descendants_only}`, при этом важно не забыть отключить наследование прав, указав `inherit_acl = %false`. ## Управление операциями { #managing-operations } Любая операция имеет связанный с ней ACL аналогично узлам Кипариса. Данный ACL можно получить из атрибута по пути `runtime_parameters/acl` операции. Права доступа имеют следующую семантику: - право `read` отвечает за чтение live preview выходных и промежуточных данных операции, а также «артефактов» её джобов: stderr, fail context, входных данных отдельных джобов; - право `manage` отвечает управлению операцией, влияющему на её состояние, то есть действиям `Abort`, `Complete`, `Suspend` и `Resume` (кнопки для них находятся в правом верхнем углу страницы операции в веб-интерфейсе); а также действиям с джобами: `Abort`, `Abandon` и `Send signal` (кнопки для них находятся в выпадающем меню в правой части страницы `Jobs` в веб-интерфейсе YTsaurus); - использование [Job Shell](https://ytsaurus.tech/docs/ru/user-guide/problems/jobshell-and-slowjobs.md) требует одновременно прав `read` и `manage` , так как наличие доступа через консоль позволяет читать или произвольным образом менять состояние джоба. Существует возможность указать ACL для операции при её запуске. Для этого в спецификации операции необходимо указать секцию `"acl"` следующего содержания: ```python yt.run_map(..., spec={"acl": [{ "action": "allow", "subjects": ["u1", "u2"], "permissions": ["read", "manage"], }]}) ``` Пользователь, запустивший операцию, и администраторы по умолчанию добавляются в результирующий ACL операции. ## Как правильно использовать ACL { #acl_usage} Представленная выше схема управления доступом весьма общая и гибкая. При ее использовании важно стараться ставить роли на максимально высоком уровне с наследованием один раз, а не управлять доступом на уровне отдельных таблиц. Наследование ACL поощряет группировать данные с общими правилами доступа в каталоги. В нормальном режиме следует иметь исключительно разрешающие записи. Запрещающие записи можно выставлять для быстрого решения проблемы, если оказалось, что доступ чрезмерно расширен, затем следует проводить ревизию ACL, и решать проблему, корректируя разрешающие записи. Не рекомендуется упоминать в ACL конкретных пользователей. При выдаче доступа вместо отдельных пользователей рекомендуется использовать группы с однотипными потребностями. Наследование ACL следует использовать везде, кроме мест, где характер доступа радикально меняется. Например, на корне Кипариса по умолчанию установлена запись, разрешающая всем пользователям (кроме `guest`) выполнять чтение. В тех местах Кипариса, где хранится чувствительная с точки зрения безопасности информация, например списки токенов, доступ переопределяется с нуля. ## Проверка ACL { #check_acl} Проверить наличие у пользователя определённого права на определённый узел Кипариса можно командой `check-permission`. ```bash yt check-permission ``` Пример запуска команды: ```bash $ yt check-permission pavel-kulenov write //tmp { "action" = "allow"; "object_id" = "1-3-411012f-1888ce1f"; "object_name" = "node //tmp"; "subject_id" = "c4-8aaa-41101f6-bec6113b"; "subject_name" = "YTsaurus"; } ``` ## Запрос доступа { #request_access } Для получения доступа к существующему аккаунту или директории в YTsaurus обратитесь к администратору системы.