Для обеспечения безопасности в System Center 2012 R2 Virtual Machine Manager используется контроль доступа на основе ролей (Role Based Access Control, RBAC). Принцип действия RBAC заключается в следующем:
Имеется несколько типов ролей пользователя. Каждая роль содержит в себе определенный набор разрешений, объединенных в профиль. Эти разрешения могут быть применены к выбранной группе объектов — области, которая определяется при создании роли. Таким образом, роль пользователя состоит из трех компонентов:
• Профиль (profile) — определяет набор действий, которые доступны пользователям с данной ролью;
• Область (scope) — определяет набор объектов, над которыми пользователь может производить действия;
• Владельцы роли (members) — пользователи, которым назначена эта роль. В качестве владельцев роли можно указывать отдельные учетные записи пользователей или группы безопасности.
В System Center 2012 R2 Virtual Machine Manager есть пять типов ролей:
Administrator
Пользователи, которым назначена эта роль, имеют неограниченные права и могут производить любые операции c VMM. Роль Administrator автоматически создается при развертывании VMM и может быть только одна в домене. Учетная запись пользователя, под которой производилась установка VMM, автоматически добавляется в администраторы.
Пользователь с ролью Administrator имеет право добавлять других пользователей в администраторы, а также создавать роли Delegated Administrator, Read-Only Administrator, Tenant Administrator и Self-Service User.
Только пользователи с ролью Administrator имеют право производить интеграцию сервера обновлений WSUS в VMM, для централизованного получения обновлений, а также добавлять хосты и кластера Citrix XenServer для их управления с помощью VMM.
Delegated Administrator
Пользователи, которым назначена эта роль, имеют неограниченные права и могут производить любые операции c VMM, но только в пределах отведенной им области, определенной при создании роли. В качестве области может выступать группа хостов, частное облако или сервер библиотеки.
Роль Delegated Administrator не создается по умолчанию, ее необходимо создать вручную. Число ролей Delegated Administrator в одном домене не ограничено, можно создать любое нужное их количество, или не создавать совсем. Члены Delegated Administrator могут добавлять новых пользователей и создавать новые роли Delegated Administrator, Read-Only Administrator и Tenant Administrator, но опять же только в пределах отведенной им области.
Пользователи с ролью Delegated Administrator не могут изменять общие настройки VMM, а также редактировать роль пользователя Administrator.
Read-Only Administrator
Роль Read-Only Administrator, как следует из названия, предназначена исключительно для просмотра. Пользователи с этой ролью могут просматривать любые настройки, а также состояние и статус выполнения административных задач, но не имеют право вносить какие либо изменения. Как и в предыдущем случае, для Read-Only Administrator при создании роли определяется область, в качестве которой может быть группа хостов или частное облако.
Tenant Administrator
Эта роль появилась в System Center 2012 SP1. Tenant в переводе означает арендатор, соответственно под ролью Tenant Administrator подразумевается администратор клиента датацентра, получившего в аренду определенный набор ресурсов, объединенный в частное облако. В отведенном им облаке пользователи с ролью Tenant Administrator могут подключаться к VMM (из консоли или через веб-портал) разворачивать и управлять виртуальными машинами, сервисами и сетями виртуальных машин. Также Tenant Administrator может создавать роли Self-Service User и управлять выделением для них ресурсов.
Application Administrator (Self-Service User)
Пользователи с ролью Self-Service User имеют право подключаться к VMM из консоли или через веб-портал и создавать и управлять виртуальными машинами и сервисами в тех пределах, которые им отведены вышестоящими администраторами. Пользователи Self-Service User не имеют прав на создание каких либо ролей в VMM.
Примечание. Только пользователи с ролью Tenant Administrator и Self-Service User могут подключаться к VMM через веб-портал самоообслуживания.
Создание ролей
Для создания новой роли пользователя надо открыть раздел Settings, перейти на вкладку User Roles и затем кликнуть на Create User Role.
Запускается мастер создания ролей. В первом окне вводим имя и описание роли.
Выбираем тип роли, один из четырех. Напомню, что роль Administrator мы создать не можем, она создается сразу при установке VMM и может быть только одна. Процесс создания ролей Read-Only Administrator и Delegated Administrator практически ничем не отличается, поэтому в качестве первого примера возьмем создание роли Delegated Administrator.
Дальше жмем кнопку «Add» и добавляем пользователей, которые будут обладателями данной роли. Можно указать как локальных, так и доменных пользователей и группы. На мой взгляд, здесь правильней будет использовать доменные группы безопасности, поэтому я создал в домене группу SC_FullAdmins, которую и назначу владельцем данной роли.
Выбираем область (Scope), в которой действуют полномочия создаваемой роли. Можно указать в качестве области частное облако, либо разрешить доступ ко всем без исключения хостам.
Примечание. Под частным облаком в VMM понимается некий абстрактный набор ресурсов (хосты, библиотеки, сети, хранилища и т.п.), объединенный по какому либо общему признаку. В VMM нет частного облака по умолчанию, его надо предварительно создать.
Указываем сервера библиотек, которыми разрешено пользоваться пользователям с данной ролью.
Указываем учетную запись RunAs Account. Можно создать новый аккаунт RunAs, либо выбрать один из существующих. RunAs Account представляет из себя контейнер для хранения учетных данных пользователя, имеющего административные полномочия в выбранной области. Создавать и редактировать RunAs Account имеют право только пользователи с ролью Administrator или Delegated Administrator.
Проверяем суммарную информацию и жмем кнопку «Finish», запуская создание роли. Если интересно, то по кнопке «View Script» можно посмотреть\сохранить команды PowerShell.
Создание роли Tenant Administrator принципиально отличается от предыдущего примера. Для ролей Read-Only и Delegated Administrator мы выбираем только область, а все полномочия заранее предопределены и неизменны. Роль Tenant Administrator напротив, позволяет детально настраивать разрешения, ограничивать количество ресурсов и определять действия, доступные для пользователей с этой ролью.
Для создания роли также запускаем мастер, из списка выбираем роль Tenant Administrator.
Добавляем пользователей, которым будет назначена эта роль.
Выбираем область для создаваемой роли. Обратите внимание, что в качестве области для роли Tenant Administrator можно указать только частное облако. Если вы хотите разрешить пользователям с этой ролью настраивать и использовать возможности динамической оптимизации нагрузки (Performance and Resource Optimization, PRO), то надо отметить чекбокс «Show PRO tips».
Определяем квоты на использование ресурсов. Квоту можно задать как в количественном выражении, прямо указав количество доступных аппаратных ресурсов (CPU, Memory, Storage), так и в относительном (Custom quota). Также можно не привязываться к аппаратным средствам, а просто ограничить количество виртуальных машин (Virtual machines), доступных для данной роли.
Примечание. Custom quota устанавливает квоту на ВМ, основываясь на очках квоты (points). Очки представляют из себя произвольное значение, которое назначается шаблону ВМ на основании ее ожидаемого размера.
Всего есть два уровня квот — на всю роль целиком (Role level) и на отдельного пользователя (Member level). Квоты можно комбинировать, например, на уровне пользователя установим лимит в 5 ВМ, а на всю роль выделим 15 виртуальных машин. Напомню, что если роль назначена на доменную группу, то для всех членов этой группы будут действовать ограничения одного пользователя.
Указываем сеть, доступную для пользователей с данной ролью.
Определяем дополнительные ресурсы (профили оборудования, файловые шары и т.п.), которые пользователь сможет использовать.
Указываем, какие операции доступны для данной роли. Здесь есть два уровня разрешений — глобальный (Global permissions) и уровень конкретной области. Полномочия создаваемой роли могут распространяться на несколько областей, соответственно можно разрешать все ″оптом″, либо для каждой области настроить отдельные разрешения.
Например, для нашей роли запретим удаление виртуальных машин в глобальных настройках
Но разрешим удалять ВМ в частном облаке Default.
Отдельно определяем квоту на создание сетей ВМ.
Добавляем RunAs аккаунт.
Проверяем суммарную информацию и жмем Finish. Еще одна роль готова 🙂
Для следующего примера выйдем из оснастки и залогинимся пользователем с ролью Tenant Administrator. Под этим пользователем мы будем создавать роль Self-Service User.
Запускаем мастер создания ролей, вводим имя и описание роли. Напомню, что для роли Tenant Administrator доступно только создание ролей Self-Service User, поэтому выбор профиля здесь отсутствует.
Добавляем пользователей\группы.
Определяем область.
И задаем для роли квоты на использование ресурсов. Принцип такой же, как и в предыдущем примере, однако теперь мы можем раздавать ресурсы только в рамках, определенных для роли Tenant Administrator. Как вы помните, мы выделили для нее 15 виртуальных машин, соответственно только это количество нам и доступно.
Определяем сеть ВМ
И дополнительные ресурсы, доступные пользователям с данной ролью.
Раздаем права. В принципе все так же, как и для Tenant Administrator, за исключением возможности создавать сети ВМ. Разрешения настраиваются очень гибко, например позволим пользователям все операции с ВМ, кроме развертывания и удаления.
Смотрим суммарную информацию и жмем Finish.
Управление ролями
Все созданные роли отображаются в разделе Settings, на вкладке User Roles. Для редактирования достаточно двойного клика мышкой по выбранной роли.
Для роли Administrator можно только изменить список пользователей.
Роли Deledated и Read-Only Administrator позволяют изменить область полномочий, а также добавлять\удалять сервера библиотеки и RunAs аккаунты.
Ну а для Tenant Administrator и Self-Service User можно изменять квоты, разрешения, доступные ресурсы и т.д.
Заключение
С помощью ролей мы можем очень тонко настраивать полномочия и управлять использованием ресурсов. Однако при большом количестве ролей в них легко запутаться, поэтому не стоит увлекаться. Ну и также желательно к каждой роли добавлять внятное описание.