← Назад к вопросам

Где храним реквизиты (адреса, логины, пароли) для плейбуков?

2.0 Middle🔥 221 комментариев
#Ansible и управление конфигурацией#Безопасность

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI5 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Управление секретами и реквизитами в Ansible

Реквизиты (credentials, secrets) — такие как пароли, ключи API, токены доступа — НИКОГДА не должны храниться в открытом виде в репозитории плейбуков или в переменных в виде plain-text. Их хранение и управление — критически важный аспект безопасности инфраструктуры как кода (IaC).

Основные подходы и инструменты

Для безопасного хранения секретов в экосистеме Ansible применяется комбинация следующих методологий и технологий:

  1. Использование Ansible Vault для шифрования чувствительных данных
    Это встроенный инструмент Ansible для шифрования переменных, файлов или целых плейбуков. Ключ шифрования (пароль или файл с ключом) хранится отдельно и не коммитится в репозиторий.

```bash
# Шифрование переменного файла
ansible-vault encrypt vars/secrets.yml

# Запуск плейбука с запросом пароля от vault
ansible-playbook site.yml --ask-vault-pass

# Или с использованием файла с паролем (права 600)
ansible-playbook site.yml --vault-password-file ~/.ansible/vault_pass.txt
```

```yaml
# Содержимое vars/secrets.yml ДО шифрования:
db_password: "{{ vault_db_password }}"
api_token: "{{ vault_api_token }}"
```
    В плейбуке или роли вы ссылаетесь на эти переменные как обычно, но их фактические значения хранятся в зашифрованном файле, который можно безопасно коммитить.

  1. Интеграция со специализированными системами управления секретами (Secrets Management)
    Для enterprise-сред предпочтительнее использовать внешние системы, которые предоставляют более продвинутые функции: ротация ключей, аудит доступа, fine-grained политики.

    *   **HashiCorp Vault**: Наиболее популярный выбор. Ansible подключается к Vault через модуль `hashi_vault` или community-коллекцию `community.hashi_vault` для динамического получения секретов во время выполнения плейбука.

```yaml
- name: Get database credentials from HashiCorp Vault
  uri:
    url: "{{ vault_url }}/v1/secret/data/{{ vault_secret_path }}"
    method: GET
    headers:
      X-Vault-Token: "{{ lookup('env', 'VAULT_TOKEN') }}"
    return_content: yes
  register: vault_result
  no_log: true  # Важно! Не логировать ответ, содержащий секреты.

- name: Set fact with database password
  set_fact:
    db_password: "{{ vault_result.json.data.data.db_pass }}"
  no_log: true
```
    *   **AWS Secrets Manager / Azure Key Vault / GCP Secret Manager**: Используются в облачных средах соответствующих провайдеров. Ansible может получать секреты через их API-модули (например, `amazon.aws.secretsmanager_secret`).

  1. Использование no_log: true для защиты секретов в выводе задач
    Даже если пароль получен из Vault, важно предотвратить его случайный вывод в лог выполнения Ansible.

```yaml
- name: Create database user with secret password
  mysql_user:
    name: app_user
    password: "{{ db_password }}"
    state: present
  no_log: true  # Эта строка не позволит паролю попасть в консоль или логи
```

Рекомендуемая практика и workflow

  • Разделение переменных: Все переменные делятся на открытые (vars/) и закрытые (vars/secrets.yml). Файл secrets.yml зашифрован с помощью ansible-vault. Его можно коммитить. В group_vars/ или host_vars/ хранятся только ссылки на имена переменных из secrets.yml.
  • Хранение пароля/ключа Vault: Пароль от Ansible Vault не должен быть в репозитории. Его передают:
    *   Через защищенные CI/CD переменные (GitLab CI, GitHub Actions Secrets, Jenkins Credentials).
    *   Через защищенные файлы на runner/host с минимальными правами доступа (`chmod 600`).
    *   Через механизмы runtime-сред (IAM-роли в AWS, позволяющие автоматически получить секрет из Secrets Manager).
  • Динамические секреты: Вместо статических паролей лучше использовать системы, генерирующие временные учетные данные (например, dynamic database credentials в HashiCorp Vault), которые автоматически отзываются после выполнения плейбука.
  • Ротация секретов: Критические секреты должны регулярно обновляться. Процесс ротации можно автоматизировать с помощью тех же плейбуков Ansible в связке с Vault.

Итог

Никакие логины, пароли или токены в чистом тексте не хранятся внутри кодовой базы плейбуков. Базовый стандарт — Ansible Vault для шифрования чувствительных файлов с переменными. В профессиональных и масштабируемых средах используется интеграция с внешним Secrets Management Vault (HashiCorp Vault, облачные аналоги), который становится единым источником истины для всех секретов в инфраструктуре. Ключ доступа к этому хранилищу (например, VAULT_TOKEN) сам управляется безопасно — через IAM-роли, файлы с ограниченными правами или переменные CI/CD пайплайна.