Общие сведения

В данном разделе собрана информация о системе контроля доступа к таблицам и другим узлам Кипариса (пользователям, группам, аккаунтам, чанкам, транзакциям и т. д.).

Любой пользовательский запрос проходит через прокси, которые аутентифицируют пользователя, то есть проверяют его подлинность. На основе содержащегося в запросе токена, полученного с помощью протокола OAuth, прокси определяет имя пользователя, инициировавшего запрос. Если токен в запросе не указан, то считается, что запрос задан от пользователя guest. После прохождения аутентификации, на последующих этапах обработки пользовательского запроса токен не используется. Подробнее о токенах можно прочитать в разделе Аутентификация.

Авторизацией (выдачей разрешений) занимается мастер-сервер Кипариса. Решение о предоставлении или отказе в доступе зависит от:

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), где каждая запись содержит перечень субъектов, тип доступа и ряд других параметров, приведённых в таблице раздела Авторизация. Подробнее читайте в секции Как правильно использовать ACL.

Пользователи, группы

В Кипарисе хранятся:

• Список всех зарегистрированных пользователей. Список хранится по адресу //sys/users и представляет собой узел типа user_map.
• Список всех зарегистрированных групп. Хранится по адресу //sys/groups и представляет собой узел типа group_map.

Как посмотреть списки пользователей и групп

Пользователи имеют тип системного объекта user. Группы имеют тип объекта group.

Как получить информацию о пользователе или группе

$ yt --proxy <cluster-name> get //sys/users/vasya/@type
"user"

$ yt --proxy <cluster-name> get //sys/users/vasya/@
{
  "id" = "ffffffff-fffffffe-101f5-1407420e";
  "type" = "user";
  "builtin" = %true;
  ...
}

$ yt --proxy <cluster-name> get //sys/groups/admins/@type
"group"

Системные субъекты

В системе YTsaurus присутствует набор субъектов, выполняющих системные функции. Таких субъектов нельзя удалить. К системным субъектам относятся:

1. Пользователи guest, root, scheduler и job;
2. Группы everyone, users, superusers.

Атрибуты субъектов

В таблице ниже представлен список атрибутов, которые имеются у всех субъектов.

Атрибуты пользователей

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

Атрибуты групп

Помимо атрибутов, присущих всем субъектам, группы имеют атрибуты, представленные в таблице ниже.

Управление группами

Чтобы создать новую группу, используется команда create. При создании не нужно указывать путь объекта, но требуется указать атрибут name.

yt create group --attributes '{name=my_group}'

Удаляются группы командой remove. При удалении группа автоматически удаляется из всех ACL, где она участвовала.

yt remove //sys/groups/my_group

Авторизация

Модуль авторизации на мастер-сервере решает следующую задачу: разрешить ли пользователю U доступ типа P для объекта O? Вариантов ответа может быть два: разрешить или не разрешать. Разберем все три компонента (U, P и O) по-отдельности.

В качестве U может выступать любой пользователь системы. Отметим, что U не может быть группой, хотя членство в группах учитывается при принятии решения. Если U — это root, то запрос доступа автоматически удовлетворяется.

Тип доступа P иначе также называется правом (permission). Права, которые поддерживаются системой YTsaurus представлены в таблице. В столбце Применяется к перечислены типы объектов, для которых право имеет смысл; для остальных типов объектов право игнорируется.

Объект 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 — только на прямых потомков (сыновей). Каждая запись имеет структуру представленную в таблице.

Как только эффективный список построен, решение о предоставлении или непредоставлении доступа принимается по следующей схеме:

1. Если в списке есть хотя бы одна разрешающая запись для U и P и нет ни одной запрещающей записи для U и P, то доступ выдается.
2. Иначе доступ запрещается.

«Запись для U и P» означает, что P упомянуто в списке permissions, а пользователь U (либо хотя бы одна группа, в которой он числится прямо или косвенно) — в списке subjects. Из представленного описания в частности следует, что если эффективный список пуст, то доступ будет запрещен.

read

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

full_read

Даёт неограниченный доступ на чтение всей таблицы, игнорируя любые ограничения на уровне колонок и строк. Для всех остальных типов объектов право full_read эквивалентно read.

Оно требуется для действий, которым нужны данные целиком, например для выполнения команд copy или move.

Поскольку это право подразумевает доступ ко всем колонкам, атрибут columns нельзя указывать в том же ACE.

use

Даёт возможность использовать ресурсы объекта:

• для аккаунта — создавать новые объекты в квоте этого аккаунта;
• для пула — запускать операции в этом пуле;
• для бандла — создавать динамические таблицы в этом бандле.

modify_children

Даёт возможность добавлять и удалять детей составного объекта. Для map-узла Кипариса создание или удаление ребёнка требует наличия права write или modify_children на родителе; выдача только modify_children позволяет субъекту управлять детьми узла, не предоставляя более широкого права write на сам узел.

register_queue_consumer

Даёт возможность зарегистрировать консьюмера очереди. ACE с этим правом имеет два особых правила: в нём должна быть указана витальность через атрибут vital (%true или %false), и оно должно содержать register_queue_consumer как единственное право. Например:

{
    action = allow;
    subjects = [my_group];
    permissions = [register_queue_consumer];
    vital = %true;
}

Владелец объекта и пользователь owner

При создании объекта пользователем U, он также становится владельцем данного объекта, что находит отражение в атрибуте owner.

Также в системе есть специальный фиктивный пользователь owner. Им невозможно аутентифицироваться, однако на него можно ссылаться в ACL в качестве субъекта. При этом в момент проверки прав owner заменяется на фактического владельца объекта. Это позволяет, например, описать ограничение «в данном каталоге удалять узлы могут только те, кто их создал» таким ACE:{action=allow; permissions=[remove]; subjects=[owner]; inheritance_mode = descendants_only}, при этом важно не забыть отключить наследование прав, указав inherit_acl = %false.

Управление операциями

Любая операция имеет связанный с ней ACL аналогично узлам Кипариса. Данный ACL можно получить из атрибута по пути runtime_parameters/acl операции.

Права доступа имеют следующую семантику:

• право read отвечает за чтение live preview выходных и промежуточных данных операции, а также «артефактов» её джобов: stderr, fail context, входных данных отдельных джобов;
• право manage отвечает управлению операцией, влияющему на её состояние, то есть действиям Abort, Complete, Suspend и Resume (кнопки для них находятся в правом верхнем углу страницы операции в веб-интерфейсе); а также действиям с джобами: Abort, Abandon и Send signal (кнопки для них находятся в выпадающем меню в правой части страницы Jobs в веб-интерфейсе YTsaurus);
• использование Job Shell требует одновременно прав read и manage , так как наличие доступа через консоль позволяет читать или произвольным образом менять состояние джоба.

Существует возможность указать ACL для операции при её запуске. Для этого в спецификации операции необходимо указать секцию "acl" следующего содержания:

yt.run_map(..., spec={"acl": [{
 "action": "allow",
 "subjects": ["u1", "u2"],
 "permissions": ["read", "manage"],
}]})

Пользователь, запустивший операцию, и администраторы по умолчанию добавляются в результирующий ACL операции.

Как правильно использовать ACL

Представленная выше схема управления доступом весьма общая и гибкая. При ее использовании важно стараться ставить роли на максимально высоком уровне с наследованием один раз, а не управлять доступом на уровне отдельных таблиц. Наследование ACL поощряет группировать данные с общими правилами доступа в каталоги.

В нормальном режиме следует иметь исключительно разрешающие записи. Запрещающие записи можно выставлять для быстрого решения проблемы, если оказалось, что доступ чрезмерно расширен, затем следует проводить ревизию ACL, и решать проблему, корректируя разрешающие записи.

Не рекомендуется упоминать в ACL конкретных пользователей. При выдаче доступа вместо отдельных пользователей рекомендуется использовать группы с однотипными потребностями.

Наследование ACL следует использовать везде, кроме мест, где характер доступа радикально меняется. Например, на корне Кипариса по умолчанию установлена запись, разрешающая всем пользователям (кроме guest) выполнять чтение. В тех местах Кипариса, где хранится чувствительная с точки зрения безопасности информация, например списки токенов, доступ переопределяется с нуля.

Проверка ACL

Проверить наличие у пользователя определённого права на определённый узел Кипариса можно командой check-permission.

yt check-permission <user_name> <permission> <folder>

Пример запуска команды:

$ 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";
}

Запрос доступа

Для получения доступа к существующему аккаунту или директории в YTsaurus обратитесь к администратору системы.