Модель доступа vStack Center

Проблема и зачем

Кластер один, а хозяев у него много: администратор платформы, администратор отдельного ВЦОД (виртуального центра обработки данных), пользователь, который работает только со своими машинами, и наблюдатель, которому нужны лишь чтение и отчёты. Все они обращаются к одному и тому же HTTPS-endpoint кластера и вызывают одни и те же методы. Разделить их одним флагом «админ / не админ» нельзя: право «посмотреть сеть» и право «изменить свою сеть» — разные права, и второе ещё и ограничено кругом объектов.

Отсюда модель из трёх слоёв, а не из одного списка ролей. Роль набирается из привилегий, привилегия перечисляет методы, которые она открывает, а scope-атрибут сужает действие привилегии до конкретных объектов. Пока эти три слоя не разложены, поведение платформы выглядит непоследовательным: пользователь с ролью администратора в одном ВЦОД получает отказ в другом, а метод, доступный «всем авторизованным», отдаёт разным ролям разный набор полей.

Эта страница объясняет модель. Как создавать и обслуживать учётные записи — в инструкции «Как управлять пользователями»; как собрать свою роль и назначить её — в инструкции «Как настроить роли и привилегии»; как устроены сессия и политика входа — в инструкции «Как настроить вход и управлять сессиями».

Модель и сущности

Доступ в vStack Center собирается из четырёх сущностей.

Пользователь. Учётная запись кластера: числовой id, имя name, полное имя fullname, метки времени created и modified. Пароля в момент создания у учётной записи нет — его задают отдельным вызовом. Рядом с профилем живут счётчики входа: failed_login_attempts, first_failed_at и locked_until. Идентификаторы id < 10 заняты встроенными учётными записями: платформа запрещает их удалять и менять им назначения ролей.

Привилегия. Единица права. У привилегии есть id, человекочитаемое name, категория category_id, набор scope_ids и главное поле — methods, список имён JSON-RPC методов, которые эта привилегия открывает. Именно привилегия, а не номер роли, отвечает на вопрос «кто может вызвать этот метод».

Scope-атрибут. Признак, по которому право сужается до части объектов. У атрибута есть id, name и флаг self_referencing. Атрибутов два вида, и разница между ними принципиальна:

Атрибут	self_referencing	Откуда берётся значение	Что ограничивает
vdc_id	false	из таблицы назначений user_role_scope	список ВЦОД, в которых действует роль
creator	true	генерируется из user_id вызывающего	объекты, созданные самим вызывающим

Роль. Именованный набор привилегий плюс набор scope-атрибутов. Роли делятся на фиксированные и кастомные по диапазону идентификатора.

ID	Имя роли	Тип	Уровень
1	Cluster Master	фиксированная	кластер
2	vDC Admin	фиксированная	ВЦОД
3	vDC User	фиксированная	ВЦОД
4	vDC Viewer	фиксированная	ВЦОД
5	Resource Viewer	фиксированная	кластер
6	Security Admin	фиксированная	кластер
7	VM Developer	фиксированная	ВЦОД
≥ 10000	своё имя, до 64 символов	кастомная	по scope-атрибутам

Роли Security Admin и VM Developer появились в 3.0.3. Первая работает на уровне кластера и открывает журнал безопасности с аудитом, вторая действует в границах ВЦОД и собрана под создание и настройку виртуальных машин.

У фиксированных ролей поле creator пустое (null), менять и удалять их нельзя. У кастомной роли creator хранит id того, кто её создал. У роли Cluster master scope-привязки нет вовсе: её scope_ids — пустой массив, поэтому она действует на весь кластер.

Пятая сущность — не объект, а связь: назначение. Роль выдаётся пользователю не «вообще», а вместе со значением scope-атрибута, то есть в границах конкретного ВЦОД. Один пользователь спокойно держит роль vDC admin в одном ВЦОД и vDC viewer в другом.

Как работает проверка доступа

Каждый запрос проходит четыре проверки подряд.

1. Сессия. Кластер проверяет токен сессии и заменяет его на числовой идентификатор пользователя — дальше внутри кластера пользователь известен по этому идентификатору. Запрос без токена отклоняется кодом -9494 («No session token») до всякой логики метода.
2. Роли вызывающего. По идентификатору собирается карта назначений: какие роли в каких ВЦОД у пользователя есть. Свою карту пользователь может посмотреть сам — в ней для каждого назначения стоят ВЦОД, роль, имя роли и признак учётной записи GI.
3. Привилегия. Метод сверяется со списком methods привилегий, которые принесли роли пользователя. Нет привилегии — отказ, и номер роли тут ни при чём: роль важна лишь как носитель привилегий.
4. Область видимости. Если у привилегии есть scope_ids, право действует только на объекты, попадающие в scope. Для vdc_id значения берутся из назначений роли, для creator — из uid вызывающего. Пустой scope_ids означает глобальную привилегию.

Разница между глобальным и суженным правом видна в самом назначении: у пары «роль — scope-атрибут» либо перечислены значения атрибута, либо стоит признак «без ограничений». Признак «без ограничений» означает, что значений в назначениях нет и роль по этому атрибуту ничем не сужена. Пример: у роли vDC admin атрибут vdc_id ограничен двумя ВЦОД, а у роли Resource viewer scope-атрибутов нет вовсе.

Привилегии сгруппированы по категориям. Категория задаёт только группировку, на проверку прав она не влияет. Набор категорий засеян в базе кластера и растёт вместе с доменами платформы. Первые десять — vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc, Auth; к ним добавлены Security, User Interface, Unified Storage, OS Image Library и Backup.

примечание

Документация API перечисляет в примере только первые десять категорий, а в базе их пятнадцать. Расхождение в примере, а не в поведении платформы: справочник категорий отдаётся целиком, поэтому опирайтесь на фактический набор разделов в своём кластере.

Пара примеров из реестра привилегий показывает оба вида ограничения:

Привилегия	Категория	Scope	Открывает метод
1000 View vDC	1 (vDC)	[1] — vdc_id	vdc-list
2010 Edit Own Network	3 (Network)	[2] — creator	net-set

Первая работает в тех ВЦОД, где роль назначена. Вторая — только на сетях, созданных самим вызывающим, независимо от ВЦОД.

Границы модели

Модель привилегий не покрывает управление самими пользователями. Значительная часть методов группы user-* требует глобальной роли и всем остальным отвечает кодом -403 с текстом "Access denied". Так ведут себя user-list, user-get, user-create, user-delete, user-unlock, user-role-assign, user-role-deassign, user-roles-map, а также методы ограничений user-remote-* и user-vhost-*. Права администратора кластера раздать частично нельзя — это осознанно закрытый контур.

Из того же принципа растут четыре запрета, о которые спотыкаются при попытке собрать «почти Cluster master» кастомной ролью:

Ограничение	Почему так	Что делать вместо
Привилегии управления ролями 7111–7113 кастомной роли не назначаются	Иначе роль сможет расширить сама себя	Оставить управление ролями за Cluster master
Self-referencing атрибут (creator) в scope_ids кастомной роли запрещён	Значение такого атрибута генерируется из user_id, привязать его к роли нечем	Использовать vdc_id, а ограничение «только своё» брать готовыми привилегиями вида Own
Фиксированные роли (id < 10000) нельзя изменить или удалить	Они несут базовые контракты платформы	Создать кастомную роль с нужным набором привилегий
Учётным записям с id < 10 нельзя менять назначения ролей и удалять их	Встроенные записи держат работоспособность кластера	Создать отдельного пользователя

Ещё одна особенность, которая удивляет при первом знакомстве: одна и та же операция может отдавать разным ролям разный объём данных. Параметры безопасности кластера читает любой авторизованный пользователь, но требования к паролю видят все, а лимит неудачных попыток и срок блокировки — только Cluster master.

Где это в интерфейсе

Учётные записи и роли живут в одном разделе. Путь: Provider Data Center → Users & Roles. Внутри раздела два таба: Users — таблица учётных записей с колонками Name, Status, Full Name, Created, Changed; Roles — таблица ролей с колонками Name, scope, Creator, Created, Modified. Колонка scope в таблице ролей — это тот самый набор scope-атрибутов роли.

Роль раскрывается на отдельном экране (в адресной строке — #/panel/allusers/roles/). Там привилегии сгруппированы по разделам: vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc, Auth, Security, User Interface. На экране фиксированной роли кнопки Actions, Reset и Save changes заблокированы — интерфейс повторяет запрет на изменение фиксированных ролей.

См. также

• Создание учётной записи, пароль, разблокировка, ограничения по сети — «Как управлять пользователями».
• Сборка кастомной роли и назначение роли в ВЦОД — «Как настроить роли и привилегии».
• Сессии, политика пароля и блокировка учётной записи — «Как настроить вход и управлять сессиями».
• Точные наборы полей и полный список кодов ошибок — «Поля и коды ошибок методов доступа».

Методы API

Операции этой страницы в API: privilege-categories, privilege-list, privilege-scopes, role-list, role-get, role-privilege-list, user-role, user-roles, user-roles-v2, user-roles-map, auth-security-settings-get — см. Справочник API.