Куди поставити пароль для Ansible-Vault

Ми плануємо використовувати ангіозний сейф у нашому проекті, щоб запобігти витоку паролів або ключів у git.

Ідея полягає в тому, щоб всі наші конфіденційні дані перенести у звичайний файл, а потім зашифрувати цей файл ansible-treult за допомогою пароля, перш ніж натиснути на git.

Щоб розшифрувати файл, нам потрібно передати пароль сховища до ansible, я думаю про три можливості:

• Зберігайте його всередині змінної серверного середовища
• Передайте його як варіант команді ansible-playbook
• Збережіть його у не модифікованому файлі.

Чи є якісь інші варіанти, який є найкращим (і безпечним) способом зберігання пароля відвідного сховища, документація найкращих практик ansible не говорить про це нічого.

Ідея полягає в тому, щоб розмістити всі наші чутливі дані [...]

Значення "всіх" у цьому реченні слід дуже ретельно проаналізувати перед реалізацією плану, який ви плануєте.

Сейф з відповіддю - дуже корисний інструмент, але його слід використовувати лише для зберігання таємниць, які є:

1. Спеціально необхідні для розгортання
2. Легко робиться марним для власників, які повинні не знати про них, але можуть незаконно "запам'ятати" їх (як правило, поза бортом)

Другий момент є критичним.

Багато людей, а можливо, і вся команда DevOps, матимуть доступ до пароля безвідмовних сховищ, а отже, і до всіх секретів.

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

Конкретно кажучи, якщо ви використовуєте ansible для розгортання бази даних та її користувачів, ви можете зберігати паролі у сховищі, але вам доведеться бути дуже обережними (і, швидше за все, розглянути інше рішення), якщо ця послуга буде доступна в Інтернеті і без необхідності будь-якої автентифікації VPN!

Користувачі (DevOps), які піддаються дії секрету, повинні бути нездатні використовувати "запам'ятовані" паролі, якщо на них накладено один бар'єр безпеки (наприклад, скасовано доступ до VPN). Крім цього, слід також скасувати доступ до сховища вихідного коду (де зберігається сховище) перед зміною паролів.

За цих умов ангібійний склепіння є дуже корисним інструментом.

Намагання зберегти секрет, який може використовувати будь-яка людина чи машина в Інтернеті у сховищі, буде натомість помилкою (наприклад, облікові дані VPN користувачів).

Чи є якісь інші варіанти, який є найкращим (і безпечним) способом зберігання пароля "ansible-treult"

За умов попереднього пункту, я вважаю, що хорошою практикою буде:

1. Зберігайте пароль сховища у зовнішньому захищеному сховищі (щось на зразок Vault від HashiCorp або будь-якого SaaS для управління обліковими даними)
2. Дозволити доступ до зовнішнього елемента сховища DevOps (їм знадобиться пароль для тестування) та системі CI / CD або контролеру ansible

3. Дотримуйтесь умову використовувати секрети ! Ви не зможете переглянути зміни в секретах, і ви не зможете проглядати відповідні змінні у файлах секретів! Тож будьте ретельними від початку. Хороша умова - називати всі змінні, що зберігаються в ангібл-склепінні, з secret_префіксом. Коли ви побачите щось на кшталт:

   postgres.yml:

   postgres_password: "{{ secret_postgres_password }}"
   

   ви будете знати, що значення зберігається в ангібі.

Ми плануємо використовувати ангіозний сейф у нашому проекті, щоб запобігти витоку паролів або ключів у git.

Оскільки ви ще нічого не реалізували, ви можете переглянути це. Використання такої системи, як Ansible treult, має ряд недоліків безпеки:

• немає аудиторського слідку того, хто до нього звернувся
• коли працівник виїжджає, їм легко взяти секретний магазин із собою
• коли працівник виїжджає, видалення їх доступу означає зміну пароля та перерозподіл його всім іншим
• скомпрометований пароль Vault treult може бути назавжди використаний у старій версії Сейфу, що зберігається в контролі версій
• секрети повинні бути статичними

Потенційно набагато більш захищеною, хоча і більш складною системою, яка не має цих недоліків, є використання Vault Hashicorp для зберігання ваших секретів. Потім ви можете витягувати з нього значення майже так само легко, як і з Vault Answer, використовуючи https://github.com/jhaals/ansible-vault .

Тоді вам доведеться керувати автентифікацією до Hashicorp Vault, але це питання про черепаху . Для людей, я вважаю, що найкращим рішенням є періодичне запрошення пароля та закінчення терміну дії маркера через короткий проміжок часу; для машин використовувати резервний аутентифікацію AWS або подібне. Ніколи не можна повністю позбутися необхідності в аутентифікації десь, але ви можете ускладнити зловмиснику доступ до нього.

Тепер, якщо налаштування та адміністрування секретного сервера для вас занадто багато, то, звичайно, ви можете просто скористатись скриншотом Ansible. Навіщо взагалі зберігати пароль на окремих машинах? Для інтерактивного використання ви можете просто запропонувати пароль, а користувачі можуть зберігати його у своєму обраному менеджері паролів. iTerm в OS X має диспетчер паролів, який інтегрується з Keychain.app, що робить його там особливо простим.

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

Я хотів би розповісти вам про свій підхід до цього та пояснити, що я вважаю за і проти. Я зберігаю пароль Ansible Vault у файлі на контрольній машині і змінна середовище вказує на нього:

export ANSIBLE_VAULT_PASSWORD_FILE=/deep/dark/place

У мене це є на моїй робочій станції (як мені потрібно тестувати та розробляти ігрові книжки), у деяких колег це є, і ми, звичайно, маємо це на головній машині управління Ansible.

Плюси:

• не в спільному розташуванні / сховищі (як ви говорите, це неперевірений файл)
• не потрібно знати свій пароль Vault Vault для того, щоб запустити гру (це за умови, що у вас є інструмент CI, наприклад, Jenkins, де ви можете легко запускати ігрові книги)

Мінуси:

• не просто повернути пароль
• кожен, хто працює над вашими ігровими книжками, повинен мати його на своєму робочому місці

Мінуси дійсно пом'якшують, але знову ж таки це залежить від політики та правил, які ви прийняли у щоденних операціях.

Погляньте на цей проект, щоб керувати паролями шифрувальних паролів з підказкою https://github.com/Smile-SA/ansible-vault-manager

Він обробляє декілька платформ зберігання брелоків із плагінами (наразі реалізовано лише AWS SSM). Інтеграція Morehover з поточним проектом Ansible дуже проста ...