Застосування Veeam Backup для віртуальних машин під управлінням Linux: аутентифікація на основі сертифіката

З виходом Veeam Backup & Replication v8 користувачі почали ретельно вивчати нові функціональні можливості продукту. А оскільки «на смак і колір товариша немає», то кожен знаходить якісь милі серцю фічі особисто для себе, причому це можуть бути зовсім скромні, «але оч-чень корисні подарунки», тобто нові опції, які відразу не кидаються в очі, але над якими копітко працювали розробники. Так підібралася «чудова вісімка», може бути, не дуже відомих, але дуже корисних фіч Veeam Backup & Replication v8. Сьогоднішня розповідь про автентифікацію за допомогою сертифіката при зверненні до гостьової ОС віртуальних машин під управлінням Linux.
image

Для чого нам потрібен доступ до гостьової ОС Linux ВМ
Індексація гостьовий файлової системи потрібно для того, щоб забезпечити користувачеві зручний пошук і швидке відновлення потрібних файлів. Зокрема, Veeam Backup & Replication 8.0 підтримує цю функціональність і для віртуальних машин під управлінням Linux, надаючи зручний веб-інтерфейс Veeam Backup Enterprise Manager:
image
Відповідні операції Veeam виконує з допомогою runtime-компонента, який запускається на гостьової ОС віртуальної машини з початком виконання завдання резервного копіювання. Цей компонент координує процеси при індексації (про них трохи пізніше), а по завершенні завдання припиняє роботу. Для роботи runtime-компонента на гостьової ОС і потрібна автентифікація, для якої Veeam Backup & Replication 8 підтримує тепер також використання сертифіката (Linux public key).

Докладніше про індексацію гостьовий файлової системи див.тут і тут (англ.яз.).

Чому ми вирішили підтримати Linux Public Key-аутентифікацію
Ті, хто працював з Linux-інфраструктурами, напевно, в курсі — рідко хто логинится на Linux сервер, вводячи ім'я користувача і пароль. Причин тому кілька, серед них, зокрема — відсутність централізованого управління обліковими записами. Так, хто використовує Microsoft Active Directory через Kerberos, хтось інші способи, але це не масове явище, і настройка і управління великою кількістю учеток в немаленькою інфраструктурі може стати головним болем для того, хто за це відповідає.

Взяти хоча б паролі: всі знають, що в цілях безпеки слід використовувати паролі достатньої складності і регулярно їх міняти. Та на це ж можна півжиття витратити! Дехто вирішує спростити завдання і використовувати, скажімо, ніколи не змінювані паролі, або прості короткі паролі. Зрозуміло, що жити стає легше, але безпеку при цьому знижується. Пам'ятаємо ще, що крім комунікації «людина-комп'ютер» є ще комунікація «комп'ютер-комп'ютер», і щоб забезпечити комунікацію між серверами, слід зберігати паролі там, де до них було б доступ програм і скриптів при цьому дуже бажано в якомусь захищеному вигляді, а не в текстовому форматі.

З-за всього цього адміністратори Linux-систем часто використовують метод автентифікації з використанням сертифіката, повністю відключаючи можливість логінитися з введенням імені та пароля. Ідея полягає в тому, щоб користувач (чи сервер) використовував для доступу через SSH до віддаленої машині сертифікат, зареєстрований на цій віддаленій машині — що і дозволяє отримати авторизацію без необхідності введення імені\пароля.

Цей сертифікат потрібно зареєструвати лише один раз, після чого доступ буде надаватися автоматично. Видачу сертифікатів також можна автоматизувати.

Якщо на Linux-сервері дозволена аутентифікація з використанням сертифіката, то при спробі залогінитися з введенням імені і пароля користувач побачить повідомлення про помилку. Єдиний можливий варіант логіна при таких налаштуваннях — якщо локальний сертифікат SSH (публічний ключ) завантажений в список дозволених ключів (authorized_keys) на сервері, куди потрібно залогінитися.При налаштуванні Veeam Backup & Replication 8.0 завдання резервного копіювання, у яке входить такий Linux-сервер, потрібно буде вказати відповідний приватний ключ.

Як це працює в Veeam Backup & Replication v8
Отже, спершу створюється пара RSA-ключів, і у вас виходить два файлу:
  • id_rsa — приватний ключ, зберігаємо його на сервері резервного копіювання. Шлях до цього ключа потрібно буде вказати при конфігурації завдання резервного копіювання.
  • id_rsa.pub — публічний ключ, його потрібно зберегти у файл authorized_keys того SSH-сервера (Linux ВМ), чию гостьову ОС ви плануєте індексувати.
До речі, в установчому каталозі Veeam присутній PuTTYGen — його можна використовувати для генерації приватних ключів PuTTY Private Key (PPK) для сервера резервного копіювання Veeam Backup & Replication. Підтримуються наступні формати SSH-ключів: OpenSSH RSA, OpenSSH DSA, OpenSSL PEM, Open SSL PKCS#8 SSH.com.

Більш детальну інформацію, а також опис роботи з Credentials Manager — інструментом для централізованого управління налаштуваннями доступу в Veeam Backup & Replication можна знайти на тут (англ.яз.).

Настроювання користувальницького доступу можна ввести і в ході створення завдання резервного копіювання або реплікації. У майстрі установки завдання резервного копіювання для Linux ВМ доходимо до кроку Guest Processing, вмикаємо опцію індексування гостьової ОС; потім в секції завдання налаштувань доступу натискаємо Add і з трьох представлених у списку способів вибираємо Linux public key:
image
У діалозі потрібно вказати, якому ім'я користувача буде ставитися у відповідність наш ключ (наприклад, root), і вказати шлях до приватного ключа, який ви до цього створили. Якщо при створенні ключа використовувалася кодова фраза (passphrase), вводимо її теж.

image

Після того, як ви вказали ключ, можна перевірити, чи спрацює він при аутентифікації — для цього після повернення до кроку Guest Processing натискаємо Test Now і спостерігаємо за процесом:
image

Ця кнопка реально корисна, оскільки при перевірці ключа перевіряється заодно і наявність всіх компонентів, необхідних для індексування гостьової ОС. Так, в прикладі вище використовувалася CentOS в мінімальній конфігурації, куди за замовчуванням не входить mlocate, про чиє відсутності і повідомила помилка в сесії. Є ще дві необхідні утиліти — це gzip tar.

Власне, основну роботу виконує mlocate, яка веде ефективний пошук файлів, використовуючи не файлову систему, а індексний БД, а Veeam використовує SSH-з'єднання для видачі вказівок» цієї утиліті (стартувати, оновити базу з допомогою updatedb, тощо). (У даному сценарії використовувати з'єднання через VMware VIX не вдасться — дана функціональність заплановано до реалізації на майбутнє, а в поточній версії сервера резервного копіювання необхідний доступ до Linux ВМ по мережі через SSH.)

Зауважимо, що оскільки звичайним користувачам може не вистачати прав для доступка до файлів і виконання команд (зокрема, індексна база закрита для читання звичайними користувачами), то рекомендується визначати в діалозі Credentials " користувача root, або включати опцію Elevate account to root.

Таким чином, mlocate видасть файли, знайдені за індексного БД, і метадані (включаючи шляху, час останнього оновлення індексу, і ін), а tar gzip відповідно складуть все це в один файл і акуратно упакують.

Після того, як всі необхідні компоненти встановлені і тест на аутентифікацію успішно пройдено, можна перейти до завершальних кроків майстра налаштування. І пам'ятаємо, зрозуміло, що ці налаштування будуть застосовуватися до всіх машинок, включених в завдання — якщо тільки не вказати інше для обраної машини (так, індивідуальні налаштування доступу до гостьової ОС можна ввести, натиснувши кнопку Credentials на відповідному кроці майстра).

Під час виконання завдання резервного копіювання у вікні статистики буде виводитися детальна інформація про хід індексування ОС Linux з використанням приватного ключа:
image
На скріншоті показано етапи процесу (позначені стрілками, зверху вниз):
  • Veeam коннектітся до Linux ВМ через SSH, використовуючи для логіна приватний ключ.
  • Потім за допомогою mlocate індексується гостьова файлова система.
  • Після цього за допомогою tar gzip створюється компактний файл індексу GuestIndexData.tar.gz.
  • В кінці роботи індексний файл публікується в каталог VBRCatalog — для того, щоб користувачі могли виконувати пошук файлів для відновлення. (Докладніше про каталозі можна почитати тут.)
Сподіваюся, нові опції роботи з віртуальними машинами під управлінням Linux знадобляться вам або вашим колегам. Однак це лише перший з 8 оповідань, продовження слід.

Додаткова інформація:


Джерело: Хабрахабр

0 коментарів

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