Для предоставления доступа различным категориям пользователей к их виртуальным машинам, как правило, используется вид ВМ и Шаблоны и система папок, на которые, собственно, и назначаются права.
Однако в некоторых случаях этого недостаточно, так как для некоторых действий пользователь должен иметь права на объекты среды, которых нет в отображении ВМ и Шаблонов.
Например, чтобы добавить виртуальный жесткий диск или клонировать виртуальную машину, вам потребуются права Datastore.Allocate Space или роль потребителя хранилища данных для объекта хранилища данных или кластера хранилищ данных.
А чтобы иметь возможность изменить сетевой интерфейс, используйте права сети Network.Assign Network или роль администратора сети для соответствующих групп портов.
Подробнее об этом и других нюансах назначения прав доступа в vSphere. Информация актуальна для версий vSphere 5.1 и 5.5. Из-за наличия разных представлений объектов инфраструктуры виртуализации права доступа к некоторым объектам (ВМ, vApps) могут быть унаследованы от нескольких предков (например, папка ВМ и Пул ресурсов).
кое-что, что следует иметь в виду.
Общая схема наследования представлена на рисунке: 
Соответственно, если кого-то нужно ограничить в правах, нужно сделать так, чтобы отнятые в одном месте права не наследовались от другого объекта.
Кроме того, вы можете столкнуться на практике с тем, что человек, имеющий права администратора на корневом уровне, вдруг оказывается ограниченным правами пользователя на уровне конкретной папки.
Дело в особенностях выбора эффективных прав в ситуации дублирования ролей.
Наделяя полномочиями, следует иметь их в виду.
1) Права, предоставленные дочерним объектам, игнорируют унаследованные.
Другими словами, если пользователь входит в группы vSphereAdmins и CitrixAdmins, при этом первый имеет права администратора на корневом уровне, а второй имеет права VM User на уровне папок Citrix, то мы получаем именно ту ситуацию, которая описана в разделе выше абзац.
2) Права, предоставленные конкретному пользователю, имеют преимущественную силу над правами, предоставленными группе.
(если оба выданы для одного и того же объекта и пользователь является членом группы).
3) Если вы используете пользователей из AD или других источников, отличных от встроенного каталога vCenter SSO, vCenter периодически проверяет доступность учетной записи путем поиска по имени .
А если после назначения прав в vCenter учетная запись была переименована или удалена, соответствующие права из vCenter удаляются.
И если в случае с удаленной учетной записью это даже хорошо, то если кто-то переименовал группу (группы), например, в соответствии с новой политикой именования в организации, это может привести к неблагоприятным последствиям.
4) vCenter SSO не наследует права от вложенных групп, если их участники не являются членами источников удостоверений.
.
Например, если домен AD не добавлен в источники удостоверений, то группа администраторов домена этого домена не будет иметь никаких полномочий на vCenter, даже если она является членом группы local\Administrators сервера vCenter. Несколько рекомендаций от лучших собаководов Best Practices по теме предоставления прав доступа.
- По возможности назначайте права группам, а не конкретным пользователям.
Управление членством в группах можно делегировать и избавить себя от лишней работы.
И даже если не делегировать, системой будет легче управлять.
- Предоставляйте права только там, где это необходимо, тем, кто в них нуждается, и с минимально необходимыми привилегиями.
Опять же, чтобы понять структуру, упростите управление и правильный контроль.
Лучше заранее сформулировать план необходимых полномочий и лиц, которые в них нуждаются.
- Используйте папки для группировки объектов со схожим набором прав.
Папки, во всяком случае, можно создавать во всех представлениях, а не только в ВМ и Шаблонах.
- Будьте осторожны при предоставлении прав на корневом уровне.
То есть на уровне самого vCenter в клиенте vSphere. Дело в том, что пользователь с правами этого уровня получает доступ не только к объектам инфраструктуры виртуализации, но и к управлению такими сущностями, как лицензии, роли, интервалы сбора статистики, сеансы и настраиваемые поля.
А возможность изменения ролей может оказать влияние даже на те vCenter, на которые у пользователя вообще нет прав (при использовании Linked Mode).
- В большинстве случаев стоит включить наследование.
Это гарантирует, что при добавлении нового объекта в определенную иерархию ответственный за него пользователь получит к нему доступ.
- Чтобы замаскировать определенные области иерархии, вы можете использовать роль «Нет доступа».
- После перезагрузки и обновления vCenter следует проверить, есть ли у вас необходимые права.
Дело в том, что если на каком-то этапе возникнут проблемы с сетью и vCenter не сможет проверить указанные группы или пользователей, они будут удалены и заменены на local\Administrators.
- Удалите права на vCenter для локальной группы «Администраторы» и пользователя «Администратор» сервера vCenter. Предоставить права специализированной группе.
Соответственно, он имеет административные права на хост и не должен ни при каких обстоятельствах обновляться (ни права, ни пароль не менять).
пользователь dcui — другой конкретный пользователь, используемый в качестве агента при работе через Пользовательский интерфейс Direct Console в режиме блокировки хоста (в этом режиме запрещены любые подключения к хосту, кроме управления с помощью vCenter).
В заключение хотелось бы отметить, что никогда еще я не осознавал в такой степени значимости и актуальности АГДЛП -подход при назначении прав доступа к системе, как при разработке политики назначения прав на объекты vCenter. Это обусловлено указанными выше особенностями и большим количеством ветвящихся элементов иерархий.
Теги: #Виртуализация #vmware #безопасность #esxi #vsphere #разрешения #Права доступа
-
Облако Для Страховщиков
19 Oct, 24 -
Строим Себе Верстак Сравнительно Недорого
19 Oct, 24 -
Позвоните В Блог
19 Oct, 24 -
Cborka Js, Конструктор Redjs
19 Oct, 24 -
Zend Framework 1.0.0 Rc1 — Выпущена
19 Oct, 24
