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

vCenter пропонує вам досить гнучку систему роздачі прав Що вона собою являє – див рис 44

Тут ви бачите списокпривілеїв (Privileges, прав), включених вроль

(role)  Administrator

Рис 44 Налаштування привілеїв на vCenter

Привілей – це право на атомарному дію На малюнку праворуч ви бачите привілеї для віртуальних машин, такі як «Створити», «Видалити», «Створити знімок стану (snapshot)» та ін Набір якихось привілеїв називається роллю

Роль – це конкретний набір привілеїв, тобто дозволених дій Роль можна дати користувачеві або групі на якийсь рівень ієрархії vCenter – див рис 45

Рис 45 Інформація про те, на який рівень ієрархії і якому користувачеві призначена обрана роль

Тут ви бачите, що роль 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 і вибираємо:

•&nbsp&nbsp&nbsp Hosts and Clusters для роздачі прав на видимі в цій ієрархії обєк-

екти – кластери, сервери, каталоги з серверами, пули ресурсів та ін

•&nbsp&nbsp&nbsp VMs and Templates – На ВМ, шаблони і каталоги з цими обєктами

•&nbsp&nbsp&nbsp Datastore – Для роздачі прав на сховища

•&nbsp&nbsp&nbsp Networking – Для роздачі прав на вКоммутатори

Подивіться на рис 46

Рис 46 Перегляд дозволів для вибраного обєкту

Тут ви бачите каталоги для ВМ (вони блакитного кольору і видно тільки в режимі «VMs and Templates») Якщо перейти на закладку Permissions, То ми побачимо інформацію про те, хто і які права має зараз на обраний обєкт

У даному прикладі ми бачимо, що група Administrators має права ролі Administrator, Притому ця роль призначена групі на рівні «vcenter4» (тобто в корені ієрархії vCenter, у мене vcenter4 – це імя машини з встановленим vCenter)

Крім того, групі «Typical_VMs_Admins» призначена роль «Resource pool administrator (sample)» на рівні «vm4ru» (у даному прикладі це назва обєкта Datacenter, яке містить всі сервери і ВМ)

Зверніть увагу Якщо ви повернетеся до рис 45, то побачите, як подивитися зворотний звязок – яка роль кому і на який обєкт призначена

Тепер ви хочете дати якісь права групи або користувачеві на обєкт в ієрархії Залишаючись на закладціPermissions цього обєкта, викликаємо контекстне меню і вибираємо Add Permissions (Рис 47)

Рис 47 Призначення ролі на каталог з ВМ

У вікні, натисканням кнопки Add ви можете вибрати користувачів і групи, потім у правій частині з випадаючого меню вибрати роль, яку хочете їм дати Бажана роль до цього моменту має бути створена, робиться це

в меню Home Administration Roles

Зверніть увагу на прапорецьPropagate to Child Objects (Застосовувати до до-

чорнимо обєктам) Якщо він не стоїть, то права видаються тільки на обєкт (каталог Project_X_VMs в моєму прикладі), але не на гілку його подобектов

У своїх прикладах я дав користувачеві «MikhailMikheev» (створеному мною в Windows, на якій встановлено vCenter) роль VMs_Admin (яку я сам створив у vCenter) на каталог Project_X_VMs Якщо тепер звернутися клієнтом vSphere від імені цього користувача, то побачимо наступну картину – див рис 48

Користувач не бачить інших обєктів, крім тих, на які має права, – тобто двох ВМ Якщо він переглядає списки подій (Events), то йому доступні події тільки цих двох обєктів Йому недоступно призначення ролей, недоступно управління ліцензіями, і далі, і далі

Далі трохи правил застосування прав

Найважливіше: якщо користувачеві видані різні права на різних рівнях ієрархії vCenter, то результуючими для якогось обєкта є перші зустрінуті знизу вгору – див рис 49

Рис 48 Підключення від імені непривілейованого користувача

Це досить типова ситуація: користувач VasilyPupkin має роль адміністратора (тобто всі права) на всю ієрархію На пул ресурсів nonCritical_ Production_VMs видані обмежені права групі користувачів, до якої входить і VasilyPupkin За правилами поширення привілеїв vCenter, для цього пулу і для вхідних в нього ВМ користувач не володіє правами адміністратора, тільки правами на читання

Чому я назвав ситуацію типовою: тому що не виключено, що адміністратор буде давати якихось груп користувачів обмежені права на групи ВМ (або мереж, або сховищ Втім, ВМ більш вірогідні) І буває,

Рис 49 Ілюстрація варіанту призначення різних прав на різні рівні ієрархії

що адміністратор сам входить, або починає входити через якийсь час, в цю саму групу І внаслідок цього втрачає адміністративні привілеї на гілку ієрархії

Інший приклад – на рис 410

Рис 410 Ілюстрація видачі різних прав двом групам на один обєкт ієрархії

Тут ви бачите, що на один і той же обєкт в ієрархії видані різні права двом групам Які права для нас будуть діяти у випадку, якщо ми входимо в обидві групи У даному випадку відбувається обєднання привілеїв – ми будемо володіти тими, що входять хоча б в одну роль

Останній приклад на рис 411

Рис 411 Видача різних прав користувачеві і групі, до якої він входить, на один обєкт

Тут на один обєкт в ієрархії видані права і безпосередньо користувачеві 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 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*