Ansible Vault: защита секретов в Ansible

Ansible Vault — встроенный инструмент Ansible для шифрования файлов и переменных. Он позволяет хранить секреты в репозиториях и расшифровывать их при выполнении плейбуков с использованием файлов паролей или интерактивного ввода. Для производственной эксплуатации рекомендуется разделять секреты по vault-id, защищать файлы паролей ACL и регулярно проводить рекейинг. В статье приведены практические советы, SOP, чек-листы и матрица рисков.

Иллюстрация Ansible Vault: безопасное хранение секретов в файле конфигурации

Быстрые ссылки

Введение в Ansible Vault
Использование Ansible Vault на практике
Рекомендации по безопасности
Заключение

С автоматизацией часто требуется доступ к защищённым ресурсам — API-ключи, пароли, сертификаты. Ключевая задача — как безопасно хранить эти учётные данные. Ansible — система автоматизации для провиженинга, управления конфигурацией и деплоя приложений. Для хранения секретов в Ansible существует встроенный механизм — Ansible Vault, который работает кроссплатформенно и использует симметричное шифрование (по умолчанию AES).

Введение в Ansible Vault

Ansible Vault позволяет шифровать любые файлы и отдельные переменные, используемые в плейбуках. По умолчанию используется AES (shared-secret). У каждого подхода — шифрование файлов и шифрование переменных — есть свои плюсы и минусы.

Шифрование файлов

Чтобы создать новый зашифрованный файл с именем

secrets.yml

воспользуйтесь командой:

ansible-vault create secrets.yml

Команда запросит пароль и откроет системный редактор по умолчанию; после сохранения файл будет зашифрован.

Чтобы зашифровать ранее незашифрованный файл, используйте:

ansible-vault encrypt secrets.yml

Недостаток шифрования файлов — уменьшенная читаемость: без расшифровки содержимое выглядит как нечитаемые данные.

Шифрование переменных

В плейбуке можно хранить зашифрованную переменную, предваряя её тегом !vault. Команда ansible-vault encrypt_string создаёт зашифрованную строку, пригодную для вставки в плейбук.

ansible-vault encrypt_string 'secret_data' --name 'my_secret'

После ввода пароля вы получите примерно такой блок:

my_secret: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  37636561366636643464376336303466613062633537323632306566653533383833366462366662
  6565353063303065303831323539656138653863353230620a653638643639333133306331336365
  62373737623337616130386137373461306535383538373162316263386165376131623631323434
  3866363862363335620a376466656164383032633338306162326639643635663936623939666238
  3161

Шифрование переменных делает плейбуки более читаемыми, но лишает возможности массового рекейинга через командную строку — такие строки нужно перешифровывать вручную.

Практическое использование Ansible Vault

В продакшне использование Vault требует организационных и технических подходов. Основные техники:

прозрачная (неинтерактивная) расшифровка
несколько хранилищ (vault-id)
рекейинг паролей

Прозрачная расшифровка

Чтобы Ansible мог автоматически расшифровывать секреты при выполнении без интерактивного ввода пароля, храните пароль в защищённом, неверсиированном файле и передавайте путь к нему через параметр --vault-password-file.

ansible-playbook --vault-password-file /path/vault-password-file secrets.yml

Важно: не коммитите файл с паролем в систему контроля версий. Ограничьте доступ к нему средствами ОС: права владельца/группы, ACL.

Важно

Защищайте файл пароля на уровне хоста: используйте минимально необходимые права доступа и, при возможности, специализированное решение для секретов.

Несколько хранилищ (vault-id)

Разделение секретов по окружениям (prod, staging, dev) или по приложениям повышает безопасность и управляемость. Ansible позволяет создавать и использовать несколько vault-id.

Создать vault с идентификатором prod, запрашивая пароль интерактивно:

ansible-vault create --vault-id prod@prompt prod-secrets.yml

Использовать файл с паролем для prod:

ansible-vault create --vault-id prod@/path/prod-vault-password-file prod-secrets.yml

Зашифровать переменную в указанном хранилище:

ansible-vault encrypt_string --vault-id prod@/path/prod-vault-password-file 'secret_data' --name 'my_secret'

В результате в метаинформации шифрованного блока появится идентификатор хранилища:

my_secret: !vault |
  $ANSIBLE_VAULT;1.1;AES256;prod
  37636561366636643464376336303466613062633537323632306566653533383833366462366662
  ...

Чтобы передать несколько хранилищ при запуске плейбука, перечислите несколько --vault-id:

ansible-playbook --vault-id dev@/path/dev-vault-password-file --vault-id prod@/path/prod-vault-password-file site.yml

Рекейинг паролей

Пароли следует периодически менять. Для зашифрованных файлов Ansible поддерживает рекейинг на уровне командной строки:

ansible-vault rekey --vault-id prod@/path/prod-vault-password-file-old --new-vault-id prod@/path/prod-vault-password-file-new site.yml

Как отмечалось выше, командный рекейинг не работает для отдельных зашифрованных переменных. Их нужно перешифровывать вручную и заменять в плейбуках.

Когда Ansible Vault не подходит

Ansible Vault — удобен и встроен, но бывают случаи, когда лучше использовать другие решения:

Требуется централизованное управление ротацией и аудит (лучше HashiCorp Vault, AWS Secrets Manager).
Нужна поддержка динамических секретов (временные креденшалы).
Нужен распределённый доступ для многих сервисов с тонкой политикой ролей (RBAC) и логированием запросов.

Альтернативные подходы

Если функциональности Ansible Vault недостаточно, рассмотрите интеграцию с менеджерами секретов:

HashiCorp Vault — мощная система с политиками, динамическими секретами и API.
AWS Secrets Manager или Parameter Store — если инфраструктура в AWS.
Azure Key Vault — для Azure-ориентированных сред.
GCP Secret Manager — для Google Cloud.

Интеграция обычно выполняется через lookup-плагины или модули, которые запрашивают секреты в рантайме и не сохраняют их в репозитории.

Практический SOP для внедрения Ansible Vault

Шаги для безопасного разворачивания использования Vault в команде:

Определите границы: какие секреты идут в Vault, а какие — в сторонние менеджеры.
Создайте структуру хранилищ: prod, stage, dev, db, ci и т.д.
Настройте механизмы хранения паролей для каждого vault-id (файлы с ограниченным доступом или вызов внешнего менеджера).
Обучите команду и документируйте рабочий процесс, включая рекейинг и процедуру на случай компрометации.
Настройте CI/CD так, чтобы файлы паролей не попадали в логи и не сохранялись в артефакты.
Внедрите регулярный аудит доступа.

Примерное playbook-процедурирование рекейинга файлов:

Остановить deployment pipeline
Создать новый файл пароля с ограниченным доступом
Выполнить ansible-vault rekey для всех файлов
Протестировать выполнение плейбуков на staging
Обновить документацию и уведомить владельцев
Включить новый файл пароля в систему управления доступом

Чек-листы по ролям

Оперативная команда

Убедиться, что файлы паролей не закоммичены
Настроить ACL для файлов паролей
Проверить, что CI/CD не логирует пароли

Разработчики

Не хранить секреты в коде
Использовать encrypt_string для локальных нужд
Тестировать работу с секретами локально через vault-password-file

Руководитель безопасности

Проводить регулярные аудит и ревизию vault-id
Заявлять политику рекейинга
Оценивать необходимость интеграции с внешним менеджером секретов

Матрица рисков и смягчение последствий

Утечка файла пароля
- Вероятность: средняя; Воздействие: высокое
- Митигаторы: ACL, мониторинг доступа, немедленный рекейинг
Компрометация репозитория с зашифрованными файлами
- Вероятность: средняя; Воздействие: среднее
- Митигаторы: разделение vault, минимизация объёма секретов в репозитории
Ошибка рекейинга, потеря доступа
- Вероятность: низкая; Воздействие: высокое
- Митигаторы: резервные ключи/процедуры восстановления, пошаговый SOP, тестирование на staging

Пример сценариев тестирования и критерии приёмки

Тесты

Запуск плейбука с правильным vault-password-file — плейбук завершается успешно.
Попытка запустить плейбук без файла пароля — ожидаемая ошибка расшифровки.
Рекейинг файла и повторный запуск — все зашифрованные ресурсы доступны.

Критерии приёмки

Отсутствие секретов в VCS в открытом виде
Плейбуки успешно выполняются в CI без интерактивных запросов
Документация SOP подтверждена и протестирована на staging

Минимальные рекомендации по защите (жёсткая конфигурация)

Права на файлы паролей: 600 (rw——-) для файлов, владелец — сервисный аккаунт или ответственный пользователь.
Не использовать общие учётные записи для хранения файлов паролей.
Логи CI не должны содержать содержимое переменных окружения, которые загружены из Vault.

Пример интеграции с внешним менеджером (идейный)

CI запрашивает токен из HashiCorp Vault через аутентификацию AppRole
Токен используется для получения секрета и временного файла пароля
Плейбук запускается с --vault-password-file указывающим на временный файл
Временный файл удаляется после выполнения

Модель зрелости использования секретов

Начальная — пароли в коде или в открытой конфигурации
Управляемая — Ansible Vault для файлов, файлы паролей локально защищены
Интегрированная — несколько vault-id, автоматизированный рекейинг
Централизованная — внешний менеджер секретов, аудит и RBAC

Модель принятия решений (схема)

flowchart TD
  A[Нужно ли централизованное ротирование и аудит?] -->|Да| B[Использовать внешний менеджер секретов]
  A -->|Нет| C[Можно использовать Ansible Vault]
  C --> D{Разделение по окружениям}
  D -->|Да| E[Создать несколько vault-id]
  D -->|Нет| F[Один vault по проекту]
  B --> G[Интегрировать через lookup/модули]
  E --> H[Документировать SOP и права]
  F --> H
  G --> H

Глоссарий

Vault-id — метка, идентифицирующая конкретное хранилище в Ansible Vault.
Rekey — процесс смены пароля для зашифрованных файлов.
ACL — контроль доступа на уровне файловой системы.

Заключение

Ansible Vault — простой и надёжный инструмент для хранения секретов рядом с плейбуками. Для безопасного использования в продакшене придерживайтесь принципов: не храните пароли в VCS, разделяйте секреты по vault-id, защищайте файлы паролей и регулярно выполняйте рекейинг. При необходимости интегрируйте Ansible с внешними менеджерами секретов для расширенного управления ротацией, аудитом и политиками доступа.

Ключевые шаги для внедрения: определить границы секретов, настроить vault-id, защитить файлы паролей с помощью ACL, автоматизировать рекейинг и протестировать процесс в staging.

Важно

Регулярно пересматривайте процесс и тестируйте процедуру восстановления — это минимизирует время простоя и снижает риски при инцидентах.