Контроль доступа, раздача прав при работе через 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 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий