Контроль доступа, раздача прав при работе через vCenter

vCenter предлагает вам достаточно гибкую систему раздачи прав. Что она собой представляет – см. рис. 4.4.

Здесь вы видите список привилегий (privileges, прав), включенных в роль

(role) Administrator.

Рис. 4.4. Настройки привилегий на vCenter

Привилегия – это право на атомарное действие. На рисунке справа вы видите привилегии для виртуальных машин, такие как «Создать», «Удалить», «Создать снимок состояния (snapshot)» и др. Набор каких-то привилегий называется ролью.

Роль – это конкретный набор привилегий, то есть разрешенных действий. Роль можно дать пользователю или группе на какой-то уровень иерархии vCenter – см. рис. 4.5.

Рис. 4.5. Информация о том, на какой уровень иерархии и какому пользователю назначена выбранная роль

Здесь вы видите, что роль Administrator (слева) дана группе Administrators на уровне объекта Datacenters (самом верхнем уровне иерархии vCenter). Это, кстати, настройки по умолчанию – группа локальных администраторов на сервере vCenter имеет все права на всю иерархию.

Кроме того, здесь эта роль выдана пользователю MikhailMikheev на пул ресурсов под названием «View».

У vCenter нет собственной БД пользователей, он пользуется:

Q локальными пользователями и группами Windows, созданными на сервере, на котором установлен vCenter;

Q доменными пользователями и группами того домена, в который входит

сервер vCenter (если он в домен входит).

Таким образом, порядок действий для выдачи каких-то прав пользователю или группе следующий:

1.    Создаем этого пользователя/группу, если они еще не существуют. Они могут быть локальными в Windows vCenter или доменными, если он входит в домен.

2.    Создаем роль. Для этого проходим Home ? Administration ? Roles. Затем:

•   в контекстном меню пустого места выбираем пункт Add для создания

новой роли с нуля;

•    в контекстном меню существующей роли выбираем пункт Clone для создания копии существующей роли. Если хотим поменять созданную роль, вызываем для нее контекстное меню и выбираем Edit.

В любом случае флажками отмечаем все необходимые привилегии.

3.    Идем Home ? Inventory и выбираем:

•    Hosts and Clusters для раздачи прав на видимые в этой иерархии объ-

екты – кластеры, серверы, каталоги с серверами, пулы ресурсов и др.;

•    VMs and Templates – на ВМ, шаблоны и каталоги с этими объектами;

•    Datastore – для раздачи прав на хранилища;

•    Networking – для раздачи прав на вКоммутаторы.

Посмотрите на рис. 4.6.

Рис. 4.6. Просмотр разрешений для выбранного объекта

Здесь вы видите каталоги для ВМ (они голубого цвета и видны только в режиме «VMs and Templates»). Если перейти на закладку Permissions, то мы увидим информацию о том, кто и какие права имеет сейчас на выбранный объект.

В данном примере мы видим, что группа Administrators имеет права роли Administrator, притом эта роль назначена группе на уровне «vcenter4» (то есть в корне иерархии vCenter, у меня vcenter4 – это имя машины с установленным vCenter).

Кроме того, группе «Typical_VMs_Admins» назначена роль «Resource pool administrator (sample)» на уровне «vm4ru» (в данном примере это название объекта Datacenter, содержащего все серверы и ВМ).

Обратите внимание. Если вы вернетесь к рис. 4.5, то увидите, как посмотреть обратную связь – какая роль кому и на какой объект назначена.

Теперь вы хотите дать некие права группе или пользователю на объект в иерархии. Оставаясь на закладке Permissions этого объекта, вызываем контекстное меню и выбираем Add Permissions (рис. 4.7).

Рис. 4.7. Назначение роли на каталог с ВМ

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

в меню Home ? Administration ? Roles.

Обратите внимание на флажок Propagate to Child Objects (применять к до-

черним объектам). Если он не стоит, то права выдаются только на объект (каталог Project_X_VMs в моем примере), но не на ветвь его подобъектов.

В своих примерах я дал пользователю «MikhailMikheev» (созданному мною в Windows, на которой установлен vCenter) роль VMs_Admin (которую я сам создал в vCenter) на каталог Project_X_VMs. Если теперь обратиться клиентом vSphere от имени этого пользователя, то увидим следующую картину – см. рис. 4.8.

Пользователь не видит других объектов, кроме тех, на которые имеет права, – то есть двух ВМ. Если он просматривает списки событий (Events), то ему доступны события только этих двух объектов. Ему недоступно назначение ролей, недоступно управление лицензиями, и далее, и далее.

Далее немного правил применения прав.

Самое важное: если пользователю выданы разные права на разных уровнях иерархии vCenter, то результирующими для какого-то объекта являются первые встреченные снизу вверх – см. рис. 4.9.

Рис. 4.8. Подключение от имени непривилегированного пользователя

Это достаточно типичная ситуация: пользователь VasilyPupkin имеет роль администратора (то есть все права) на всю иерархию. На пул ресурсов nonCritical_ Production_VMs выданы ограниченные права группе пользователей, в которую входит и VasilyPupkin. По правилам распространения привилегий vCenter, для этого пула и для входящих в него ВМ пользователь не обладает правами администратора, только правами на чтение.

Почему я назвал ситуацию типичной: потому что не исключено, что администратор будет давать каким-то группам пользователей ограниченные права на группы ВМ (или сетей, или хранилищ. Впрочем, ВМ более вероятны). И бывает,

Рис. 4.9. Иллюстрация варианта назначения разных прав на разные уровни иерархии

что администратор сам входит, или начинает входить через какое-то время, в эту самую группу. И вследствие этого теряет административные привилегии на ветвь иерархии.

Другой пример – на рис. 4.10.

Рис. 4.10. Иллюстрация выдачи разных прав двум группам на один объект иерархии

Здесь вы видите, что на один и тот же объект в иерархии выданы разные права двум группам. Какие права для нас будут действовать в случае, если мы входим в обе группы? В данном случае происходит объединение привилегий – мы будем обладать теми, что входят хотя бы в одну роль.

Последний пример на рис. 4.11.

Рис. 4.11. Выдача разных прав пользователю и группе, в которую он входит, на один объект

Здесь на один объект в иерархии выданы права и непосредственно пользователю MikhailMikheev, и группам, в которые он входит. В данном случае результи рующими являются только те права, что выданы непосредственно пользователю. В моем примере это роль «No access». Эта существующая по умолчанию роль необходима, как вы понимаете, для явного лишения доступа.

Общие соображения по разграничению прав доступа

Если в компании один администратор, то, скорее всего, вам система раздачи прав не пригодится или пригодится очень ограниченно – на уровне предоставле ния прав на некоторые ВМ некоторым группам пользователей.

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

1.    Составьте перечень повседневных задач, которые придется решать. Если что-то забудете – ничего страшного, выполните несколько итераций.

2.    Перечислите, какие объекты иерархии и элементы интерфейса использу ются для выполнения каждой задачи из списка, составленного выше. Про каждую, и подробно.

3.    Распишите, кто и где будет это выполнять.

Полученный в результате документ называется «матрицей доступа к инфор мации». Кто, куда, зачем. Фактически это – основа внутренней документации по безопасности виртуальной инфраструктуры, на ее основе будут создаваться роли и выдаваться на те или иные уровни иерархии, с ее помощью будут фиксироваться изменения. Наличие документации, куда вносятся изменения в конфигурации, является обязательным – иначе вы рискуете в какой-то момент запутаться вплоть до потери доступа к инфраструктуре.

Не используйте роли, существующие в vCenter по умолчанию. За исключением роли Administrator (то есть все права), Read-only (просмотр информации об объекте) и No Access (явное отсутствие доступа). Прочие существующие по умолчанию роли использовать не рекомендуется (кроме роли VMware Consolidated Backup user (sample)).

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

Однозначно роли должны назначаться персонифицированно, то есть не должно быть учетной записи, из-под которой могут аутентифицироваться несколько человек. Это чрезвычайно помогает, в частности если необходимо восстановить последовательность событий и виновное лицо.

Не используйте локальных учетных записей, кроме исключительных случаев. Только доменные. Тем более это удобнее – для аутентификации в vSphere можно использовать ту учетную запись, от имени которой был выполнен вход в Windows, и не набирать пароль заново.

Не забывайте о настройках по умолчанию: локальная группа администраторов имеет все права на корень иерархии vCenter. Конечно же правильно будет:

1.    Создать персонифицированную учетную запись (даже две).

2.    Наделить их правами администратора на все в vCenter.

3.    Убрать их данные в сейф, пользоваться ими лишь в исключительных случаях.

4.    Лишить группу локальных администраторов прав в vCenter.

Источник: Михеев М. О. Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.