Як керувати своїми проектами OpenStack за допомогою доменів Keystone в релізі Havana

    Автор Сергій Кашаба
 
Домени в OpenStack — це метод об'єднання проектів або орендарів (як вони називалися в Grizzly) в незалежні групи. Крім того, вони дозволяють вам обмежити доступ до певного домену. Наприклад, як ви, напевно, пам'ятаєте, коли домени не застосовувалися, користувач, якому була призначена роль адміністратора в одному проекті, був адміністратором всього кластера і міг виконувати будь-які операції. C появою доменів ви можете призначити користувачеві роль адміністратора в одному домені з привілеями адміністратора тільки в цьому домені.
У даній статті будуть коротко розглянуті деякі ситуації, в яких домени можуть вам допомогти організувати свої проекти. Як тільки ви розберетеся з цим, ми перейдемо до розгляду того, як на ділі використовувати домени з цією метою.
 
 

Мотивація

Вперше ми зіткнулися з доменами приблизно рік тому, коли один з наших корпоративних клієнтів запросив функціональність, дуже схожу з доменами OpenStack. Це було в рамках циклу Grizzly. Ми прочитали про це і сказали: «Йо-хо-хо! Ми можемо використовувати функціональність доменів! ». На той момент вона була тільки що введена.
 
Але OpenStack — це… OpenStack, і дана функціональність підтримувалася не всіма необхідними компонентами. Тому ми зробили патч для Keystone, щоб реалізувати запитувані сценарії використання і вирішили повернутися до цього пізніше.
 
Через півроку вийшов реліз Havana. Оскільки функціональність доменів вельми корисна для корпоративного сегмента, ми вирішили отримати доказ правильності концепції з використанням релізу vanilla Havana.
 
Ми хотіли охопити наступні сценарії використання:
1.Як адміністратор IaaS я повинен мати можливість створювати домени для агрегування орендарів (які тепер називаються проектами).
 
2.Як адміністратор IaaS я повинен мати можливість додавати користувача в ролі адміністратора домену.
 
3.Як адміністратор домену я повинен мати можливість:
 
• Створювати, видаляти, переміщати, оновлювати і видаляти проекти усередині даного домена. У списку проектів повинен бути тільки проект цього домену.
 
• Виконувати CRUD-операції над користувачем стосовно до ролям проекту.
 
4.У якості джерела імені користувача / пароля повинен використовуватися LDAP.
 
5.Обязательно використовувати тільки REST API. Ні UI, ні CLI не потрібні.
 
На цей раз у нас вийшло. Не скажу, що не було ніяких проблем, але проект показав, що домени в релізі Havana, як мінімум, можуть застосовуватися.
 
 

На старт, увага, марш!

Ми протестували домени, використовуючи гілку stable / havana в Devstack. Файл localrc містить тільки параметри для надання паролів.
 
У процесі дослідження ми з'ясували, що CLI лише частково готовий до використання доменів. Він надає повну функціональність для звичайного користувача, але не всю для адміністрування (тут ).
 
Для використання функціональності доменів потрібно зробити наступне:
1.Поменять формат маркера на UUID (файл keystone.conf, розділ [signing], token_format = UUID). У Glance є проблеми з маркерами PKI (як мінімум, з маркерами v3), і при аутентифікації видається помилка 'body is too large' («занадто велике тіло») при використанні PKI, заданої за замовчуванням (проблема виникає не тільки при використанні доменів).
 
2.Пріменіть коректний файл policy.json для keystone. Перевірка доменів не підтримуються в заданому за замовчуванням файлі політик. Ми повторно використовували файл, який йде в комплекті з keystone з git , а потім внесли до нього зміни .
 
3.Ізменіть налаштування Nova, Glance-api і конфігураційних файлів paste.registry в Glance для можливості використання аутентифікації V3.0 шляхом додавання 'auth_version = v3.0' в розділ [filter: authtoken]. У тестовому оточенні ми використовували тільки Nova і Glance для запуску VM. Якщо ви використовуєте і інші сервіси, не забудьте внести зміни до відповідних конфігураційні файли. Якщо цього не зробити, клієнти Nova і Glance перевірятимуть маркери V2 і видавати помилку "Only default domain is allowed over the V2.0" («В V2.0 може бути використаний тільки домен, встановлений за умовчанням»).
 
4.Обновіть кінцеві точки keystone, щоб сервіс identity вказував на v3, а не v2.0.
 
5.Перезапустіть сервіси, в налаштування яких були внесені зміни.
 
Зверніть увагу на те, що на вимогу клієнта ми використовували тільки інтерфейс REST і не використовували клієнти CLI / PythonAPI / UI.
 
 

Як управляти доменами

Витративши близько тижня на вивчення доменів, я можу сказати, що є два ключових моменти для розуміння того, як вони працюють:
1.Як створюється маркер і, зокрема, область маркера (token scope).
 
2.Як запускаються політики.
 
У даній статті всі приклади будуть наведені з використанням команд curl. Це зроблено з двох причин. По-перше, при написанні даного документа CLI не підтримував завдання пов'язаних з доменом параметрів через командний рядок. По-друге, що практично важливіше, CLI не розкриває деякі деталі, істотні для розуміння того, як він працює.
 
 
Створення маркера

Для початку треба створити маркер, що досить просто. Це робиться за допомогою наступного запиту:
 
curl-si-X POST-H "Content-Type: application / json"-d '{"auth": {"scope": {"domain": {"id": "XXXXX"}}, "identity": {"password": {"user": {"domain": {"name": "default"}, "password": "qwerty", "id": "YYYYYY"}}, "methods": [«password »]}}}" 127.0.0.1 : 5000/v3/auth/tokens | awk '/ X-Subject-Token / {print $ 2}' | tr-d '\ r'
 
Тут видно важлива частина файлу json, яка передається як тіла, — область (scope). Областю може бути або домен, або проект. Область маркера бере участь у запуску політики, тому це важливо зрозуміти і запам'ятати. Якщо цікаво, можете заглянути в function keystone / auth / controllers.py: AuthInfo._validate_and_normalize_scope_data, щоб дізнатися код, який використовували при створенні об'єкта, який потім застосовувався для генерації даних політики (policy credentials).
 
 
Запуск політики

Запуск політики — справа більш складна. Це основний сценарій використання. На щастя, як тільки у вас буде чітке розуміння того, як це відбувається, ви зможете виконувати більшість операцій у сфері доменів. При запуску політики використовуються три нових ключових слова: credential, policy і target. Тепер подивимося, в чому полягає створення і використання кожного з них.
 
 
Облікові дані (Credentials)
Об'єкт credential — це словник, створюваний на основі маркера і включає область отриманого маркера, а також ролі, призначені користувачеві.
 
 
Політика (Policy)
Політика — це просто набір правил, об'єднаних відповідно до логіки OR / AND. У майбутніх релізах вона повинна стати більш розбірливо і, але поки ми будемо застосовувати використовуваний в даний час формат. Нижче представлені окремі фрагменти політики як приклад вищесказаного.
 
"Admin_required": [[«role: admin»]],
 
"Owner": [[«user_id:% (user_id) s»], [«user_id:% (target.entity.user_id) s»]],
 
"Identity: get_project": [[«rule: admin_required»,
«Domain_id:% (target.project.domain_id) s»]],
 
"Identity: list_projects": [[«rule: admin_required», «domain_id:% (domain_id) s»]],
 
"Identity: list_user_projects": [[«rule: owner»], [«rule: admin_required»,
«Domain_id:% (domain_id) s»]],
 
Все має бути укладена в квадратні дужки ([]).
 
Мінімальний фрагмент правила (можна назвати його «атомарним» правилом) — це стринг з двокрапкою в якості роздільника (':'). Це може бути:
1.Ссилка на інше правило. У цьому випадку ліва частина — це «правило», а права — ім'я правила.
 
2.Визначення логіки перевірки правильності. У цьому випадку ліва частина визначає ключ, який знаходиться в об'єкті credential, а права частина — щось, що знаходиться в 'target'. Також це може бути константа. Це можна виразити як credentials_object [left_side] == right_side% target_object.
 
Кілька атомарних правил можуть бути об'єднані з використанням комою (,). Це означає, що ці правила об'єднані на основі логіки AND (наприклад: [«rule: admin_required», «domain_id:% (domain_id) s»]). Назвемо це «правилом and».
 
Якщо є два набору правил, укладених в [], то вони об'єднуються на основі логіки OR. Наприклад, [[«rule: owner»], [«rule: admin_required»]] означає, що правило виконується, якщо виконується правило власника або правило, необхідний адміністратором.
 
Якщо правило використовує інше правило, то правило, укладену в дужки, потрібно описати таким же чином.
 
Підіб'ємо підсумок: приклад '"identity: list_user_projects": [[«rule: owner»], [«rule: admin_required», «domain_id:% (domain_id) s»]] означає «список проектів користувача дозволений, тільки якщо виконується правило з ім'ям 'owner' АБО виконується і правило, необхідний адміністратором, І domain_id з області маркера дорівнює domain id з target '. Тепер мова піде про мету.
 
 
Мета (Target)
Об'єкт target також є словником, створюваним на основі наступного:
 • рядок запиту (query string) із запиту (request);
 
• запускаються об'єкти.
 
Наприклад:
 • Якщо ми намагаємося отримати інформацію про проект, то метою є цей проект
 
• Якщо ми намагаємося призначити для проекту користувача з певною роллю, то метою є роль + проект + користувач.
 
• Якщо ми намагаємося перерахувати всі проекти, то значення мети буде порожнім (Спочатку це мене засмутило, тому що я думав, що деякі з операцій, запитуваних нашими клієнтами, були недоступні в релізі Havana. Але нам пощастило, я помилявся.).
 
• Якщо ми намагаємося перерахувати всі проекти, застосовуючи фільтр за певним значенням (наприме, по domains_id), то мета включає всі фільтри (Це було для мене сюрпризом, але виявилося дуже корисним).
 
Приклад запиту:
 
curl-sX GET-H "X-Auth-Token: $ OS_MYTOKEN" 127.0.0.1 : 5000/v3/projects? domain_id = $ OS_DOMAIN_ID
 
У даному запиті в ціль входить тільки domain_id. Правилом, яке слід включити в файл policy.json, може бути "identity: list_projects": [[«rule: admin_required», «domain_id:% (domain_id) s»]].
 
Знаючи все це, ви можете легко управляти доступом, вносячи зміни в файл policy.json.
Крім того, в keystone / policy / backends / rules.py: enforce можна записувати налагоджувальні повідомлення для протоколювання облікових даних, правил і цілі для більш ретельного аналізу. Цей метод допоміг мені зрозуміти, що відбувається в деяких сценаріях використання.
 
 
Адміністратор хмари (Cloud admin)

За існуючим файлу policy.json мені було незрозуміло, що означало правило 'cloud_admin':
 
"Cloud_admin": "rule: admin_required and domain_id: admin_domain_id",
"Identity: get_domain": "rule: cloud_admin",
 
Провівши деякий дослідження, я з'ясував, що це вельми вишукане обхідне рішення для визначення 'super administrator' без використання маркера сервісу. Ви просто створюєте домен, який є 'super domain', і вказуєте відповідний ID як значення admin_domain_id в правилі. Наприклад, в devstack можна використовувати 'default', і вказати домен, заданий за замовчуванням, як 'super' адміністратора.
Згідно обговоренню ключових керівників Keystone, поняття адміністратора хмари є тимчасовим рішенням і буде замінено поняттям адміністратора сервісу .
 
 

Підтримка Horizon

Відповідно до блюпрінтамі Horizon також може підтримувати декілька доменів. Для цього потрібно внести лише незначні зміни або в settings.py, або в local_setting (які ми тестували в нашій лабораторії):
 
OPENSTACK_API_VERSIONS = {
"Identity": 3
}
 
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
# OPENSTACK_KEYSTONE_URL = "% s: 5000/v2.0"% OPENSTACK_HOST
OPENSTACK_KEYSTONE_URL = "% s: 5000/v3"% OPENSTACK_HOST
Внісши дані зміни, ви отримаєте додаткове поле введення на етапі входу в систему для вказівки імені домена. На жаль, дії адміністратора (такі як управління доменами і призначення) недоступні в Horizon при застосуванні до keystone політики V3 (keystone .
 
2.Невозможно видалити домен, якщо ви призначили якого проекту домену користувача з іншого домену. Проблема .
 
 

Висновки

Підводячи підсумки, можна сказати, що для використання функціональності доменів в Horizon, необхідно для початку переконатися, що ви використовуєте Keystone API версії V3 і що ви поміняли схему аутентифікації на UUID. Потім потрібно створити маркери, після чого створити і запустити відповідні політики. Виконавши це, ви можете використовувати команди з наведеного списку для створення і використання доменів, також можна використовувати Horizon або нові параметри CLI.
 
Оригінал статті англійською мовою .
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.