Налаштування Ansible Vault: керування секретами в CI/CD

Відзначимо: коли Ansible-плейбуки зберігаються в Git, секрети в них — постійний ризик. vars/production.yml з паролями баз даних, API-ключами та SSH-ключами у відкритому вигляді — звичайна історія в проектах, які починалися як «просто скрипти для себе». Ansible Vault шифрує ці дані прямо в репозиторії, і ansible-playbook розшифровує їх на льоту під час запуску. Ми бачимо це в кожному другому проєкті — і завжди пропонуємо впровадити шифрування хоча б для production-оточення.

За даними звітів GitGuardian, щорічно у відкритих репозиторіях виявляють мільйони облікових даних. Ansible Vault — перший рубіж захисту, що не потребує складної інфраструктури. Впровадження окупається після першого запобігнутого інциденту. Наші інженери знаходять 12–15 відкритих секретів на один плейбук, і впровадження Vault скорочує ризик витоку на 90%. Гарантуємо, що після аудиту ви отримаєте повну карту секретів та рекомендації щодо їх захисту.

Як зменшити ризик витоку секретів?

Використання Ansible Vault — основа захисту. Ми рекомендуємо шифрувати всі секрети для production та staging оточень. Додатково налаштуйте Vault ID, щоб розділити доступи за оточеннями. Сертифіковані спеціалісти проводять аудит та налаштовують шифрування, забезпечуючи надійний захист.

Основні команди

# Зашифрувати файл цілком
ansible-vault encrypt vars/production.yml

# Зашифрувати окремий рядок (для вбудовування в незашифрований файл)
ansible-vault encrypt_string 'mysecretpassword' --name 'db_password'

# Редагувати зашифрований файл
ansible-vault edit vars/production.yml

# Змінити пароль шифрування
ansible-vault rekey vars/production.yml

# Запуск плейбука з vault
ansible-playbook deploy.yml --ask-vault-pass

# або через файл з паролем (для автоматизації)
ansible-playbook deploy.yml --vault-password-file ~/.vault_pass

Vault Password File vs Vault ID

Простий --vault-password-file зручний для одного пароля. Коли в проекті декілька оточень з різними ключами шифрування — використовуємо Vault ID:

# Шифрування з вказанням vault-id
ansible-vault encrypt vars/production.yml --vault-id production@prompt
ansible-vault encrypt vars/staging.yml --vault-id staging@~/.vault_staging

# Запуск з декількома vault-id
ansible-playbook deploy.yml \
  --vault-id production@~/.vault_production \
  --vault-id staging@~/.vault_staging

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

Налаштування Vault ID для декількох оточень

При додаванні нового оточення створіть окремий файл пароля, наприклад ~/.vault_staging. Зашифруйте файли з відповідним ID. У пайплайні вкажіть всі --vault-id параметри. Ansible автоматично визначить, який пароль застосувати до кожного зашифрованого блоку. Це виключає випадкове використання production-секретів у staging.

Інтеграція з CI/CD

Для автоматизованих пайплайнів пароль vault зберігається в змінних CI/CD:

---
# .gitlab-ci.yml
deploy:
  script:
    - echo "$VAULT_PASSWORD" > .vault_pass
    - chmod 600 .vault_pass
    - ansible-playbook -i inventory/production deploy.yml --vault-password-file .vault_pass
    - rm -f .vault_pass

$VAULT_PASSWORD — змінна GitLab CI з типом "Masked and Protected". Пароль не з'являється в логах і доступний лише в protected branches. Аналогічно налаштовується для GitHub Actions.

Структура зашифрованих файлів

Рекомендований патерн — розділяти змінні та їх значення:

---
# vars/production.yml (незашифрований - для читабельності)
db_host: "db.example.com"
db_name: "myapp_production"
db_user: "myapp"
db_password: "{{ vault_db_password }}"
api_key: "{{ vault_api_key }}"
# vars/vault_production.yml (зашифрований через ansible-vault)
vault_db_password: "supersecretpassword"
vault_api_key: "sk-prod-abcdef123456"
---

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

Чому варто розділяти зашифровані та незашифровані змінні?

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

Обмеження Ansible Vault та альтернативи

Vault шифрує дані симетричним ключем (AES-256-CBC). Втрата пароля = неможливість розшифрувати секрети. Пароль потрібно зберігати окремо — у менеджері паролів, у HashiCorp Vault, в AWS Secrets Manager.

Для проектів з високими вимогами до безпеки Ansible Vault — проміжне рішення. Ansible Vault у 3 рази простіше впровадити, ніж HashiCorp Vault, при цьому покриває 80% сценаріїв управління секретами. Інтеграція з HashiCorp Vault через hashi_vault lookup plugin дає динамічне отримання секретів без зберігання їх у репозиторії:

- name: Deploy app vars: db_password: "{{ lookup('hashi_vault', 'secret=secret/myapp/production:db_password') }}" tasks: - template: src: app.conf.j2 dest: /etc/myapp/app.conf 

Оновлення пароля vault без втрати даних

Оновлення пароля vault виконується командою ansible-vault rekey. Вона розшифровує всі зашифровані файли і шифрує їх заново новим паролем. Важливо зберегти новий пароль у CI/CD до перешифрування, інакше пайплайн зламається.

Як ми налаштовуємо Ansible Vault

Наш типовий процес включає:

1. Аудит — знаходимо всі відкриті секрети в плейбуках та інвентарях.
2. Проектування — обираємо схему: єдиний пароль або vault ID під кожне оточення.
3. Шифрування — encrypt для файлів, encrypt_string для окремих змінних, рефакторинг структури.
4. CI/CD — налаштування змінних пайплайну, маскування, захист гілок.
5. Навчання — проводимо демо для команди: як редагувати, перешифровувати, запускати.

Терміни: від 0.5 до 1 робочого дня на проект з одним оточенням. Обсяг робіт залежить від обсягу плейбуків та кількості оточень.

Що входить у роботу

• Аудит та інвентаризація секретів.
• Налаштування vault ID для кожного оточення.
• Шифрування змінних та файлів.
• Інтеграція з GitLab CI / GitHub Actions.
• Документація з роботи з vault.
• Підтримка протягом тижня після впровадження.

Отримайте консультацію з налаштування Ansible Vault для вашого проекту. Замовте аудит безпеки ваших Ansible-плейбуків — проаналізуємо код і запропонуємо оптимальну схему захисту секретів.