Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется представление VM and Templates и система папок, на которые, собственно, и назначаются права. Однако, в некоторых случаях этого бывает недостаточно, поскольку для некоторых действий пользователь должен иметь права и на объекты среды, отсутствующие в отображении VM and Templates. Например, для добавления виртуального жёсткого диска или клонирования ВМ нужны права Datastore.Allocate Space или роль Datastore Consumer на объект Datastore или Datastore Cluster. А для возможности изменения сетевого интерфейса — права Network.Assign Network или роль Network Administrator на соответствующие портгруппы. Далее детальнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5.

Ввиду наличия различных представлений объектов инфраструктуры виртуализации, права доступа к некоторым объектам (VM, vApps) могут наследоваться от нескольких предков (например, VM folder и Resource Pool). что стоит иметь ввиду. Общая схема наследования представлена на рисунке:

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

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

1) Права, выданные дочерним объектам игнорируют наследованные. Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первая имеет права админа на уровне root, а вторая — VM User на уровне папки Citrix, то как раз получим ситуацию, описанную в вышеприведённом абзаце.

2) Права выданные на конкретного пользователя преобладают над правами, выданными на группу (если и те и другие выданы на один объект и пользователь входит в группу).

3) Если используются пользователи из AD или иных источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет наличие учётной записи поиском по имени. И если после назначения прав в vCenter, учётка была переименована или удалена, соответствующие ей права из vCenter удаляются. И если в случае удалённой учётки это даже хорошо, то в случае, если кто-то переименовал группу (группы), например в соответствие с новыми политиками именования в организации, это может привести к неблагоприятным последствиям.

4) vCenter SSO не наследует права вложенных групп, если их участники не входят в Identity Sources. Например, если домен AD не добавлен в Identity Sources, то группа Domain Admins этого домена не будет иметь никаких полномочий на vCenter, даже с учётом того, что она входит в local\Administrators сервера vCenter.

Немного рекомендаций ~~лучших собаководов~~ Best Practices по теме предоставления прав доступа.

По возможности назначать права на группы, а не на конкретных пользователей. Контроль членства в группах можно делегировать и избавить себя от лишней работы. И даже если не делегировать, системой будет проще управлять.
Выдавать права только там, где необходимо, тем, кому необходимо и с минимально необходимыми привилегиями. Опять же для понимания структуры, упрощения управления и должного контроля. Лучше сформировать заранее план необходимых полномочий и лиц, которым они нужны.
Использовать папки для группировки объектов со схожими наборами прав. Папки, если что, можно создавать во всех представлениях, а не только в VM and Templates.
Быть аккуратнее с предоставлением прав на корневом уровне. То есть на уровне самого vCenter в клиенте vSphere. Дело в том, что пользователь, имеющий права на этом уровне получает доступ не только к объектам инфраструктуры виртуализации, но и к управлению такими сущностями как лицензии, роли, интервалы сбора статистики, сессии и кастомизированные поля. А возможность модификации ролей может оказать влияние даже на те vCenter, на которые у пользователя вообще нет прав (при использовании Linked Mode).
В большинстве случаев стоит включать наследование. Это гарантирует, что при добавлении нового объекта в определённую иерархию, пользователь, за него ответственный, получит к нему доступ.
Для маскировки специфичных зон иерархии можно использовать роль «No Access»
После перезагрузки и обновления vCenter стоит проверять наличие необходимых прав. Дело в том, что если на каком-то этапе возникли сетевые проблемы и vCenter не сможет верифицировать указанные группы или пользователей, они будут удалены и заменены local\Administrators.
Удалить права на vCenter для локальной группы Administrators и пользователя Administrator сервера vCenter. Выдать права специализированной группе.

Напоследок упомяну о специализированных пользователях хостов ESXi. Спровоцировано тем, что коллега однажды решил убедиться, что сотрудники ИТ в некоторых регионах не наделали себе лазеек в инфраструктуре, и чуть было не вычистил ESXi-хосты от пользователя vpxuser.

vpxuser — специализированный пользователь, который создаётся при подключении хоста к vCenter и используется им для администрирования. Имеет, соответственно, административные права на хост и ни в коем случае не должен модернизироваться (не менять ни права ни пароль).

dcui user — ещё один специфичный пользователь, используемый в качестве агента при работе через Direct Console User Interface режиме lockdown mode хоста (в этом режиме любые подключения к хосту запрещены, кроме управления с помощью vCenter).

В качестве заключения хочу заметить, что никогда я настолько не осознавал значимости и актуальности AGDLP-подхода при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Ввиду вышеприведённых особенностей и большого количества ветвлений элементов иерархий.

Некоторые замечания на тему VMware vSphere Security Permissions