Настройка Ansible Vault: управление секретами в CI/CD

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

По данным отчётов GitGuardian, ежегодно в открытых репозиториях обнаруживают миллионы учётных данных. Ansible Vault — первый рубеж защиты, не требующий сложной инфраструктуры. Внедрение окупается после первого предотвращённого инцидента: ущерб от утечки паролей может достигать $2.7k–3.9k., а экономия средств при предотвращении одного инцидента составляет в среднем $1.4k–1.9k. Наши инженеры находят 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-плейбуков — проанализируем код и предложим оптимальную схему защиты секретов.