Где хранить реквизиты стенда в Ansible playbook?

Стратегии управления реквизитами стенда в Ansible

Вопрос о хранении реквизитов (credentials) для стендов (stand) в Ansible — это фундаментальная проблема безопасности и управления конфигурацией в DevOps. Прямое хранение паролей, ключей или токенов в playbook или переменных в виде plain-text является грубой ошибкой и нарушением базовых принципов безопасности. Существует несколько проверенных и безопасных подходов, которые следует комбинировать в зависимости от контекста и требований стенда.

Основные принципы и лучшие практики

1. Разделение конфигурации и секретов: Playbooks и роли должны описывать структуру и состояние стенда (какие пакеты установить, какие конфигурации применять), а сами секретные данные должны поступать из внешних, защищённых источников.
2. Минимизация распространения секретов: Реквизиты должны быть доступны только для конкретных задач и на конкретных узлах, где они необходимы.
3. Использование безопасных хранилищ: Все решения должны поддерживать шифрование, управление доступом (RBAC) и возможность аудита.
4. Динамическое получение секретов: Идеальный подход — получение реквизитов непосредственно во время выполнения playbook из специализированного сервиса.

Конкретные методы и технологии

1. Ansible Vault для локального и статического управления

Ansible Vault — это стандартный инструмент в составе Ansible для шифрования конфиденциальных данных. Он идеально подходит для небольших проектов, демонстрационных стендов или когда использование внешних систем нецелесообразно.

• Как использовать: Вы создаете файл (например, stand_credentials.yml) с реквизитами и шифруете его с помощью пароля или ключа.
• Интеграция в Playbook: Зашифрованный файл включается как переменные через include_vars или объявляется в ansible-playbook командой с флагом --ask-vault-pass или через vault-пароль в файле.

# Пример encrypted_vars.yml (создан через ansible-vault create)
db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          663864396532363339653... (шифрованный текст)
api_token: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          234234324324324324324...

# В playbook или в vars_files главного playbook
- hosts: stand_servers
  vars_files:
    - encrypted_vars.yml
  tasks:
    - name: Configure database connection
      template:
        src: db_config.j2
        dest: /app/config/database.conf
      # В шаблоне db_config.j2 можно использовать {{ db_password }}

Недостаток: Пароль для vault нужно как-то передавать в процесс выполнения (через файл, переменную окружения или ввод). Это создает свою проблему безопасности.

2. Внешние системы управления секретами (Secrets Management)

Это наиболее правильный и безопасный подход для production-стендов. Ansible может получать реквизиты динамически из таких систем.

• HashiCorp Vault: Лидер рынка. Ansible интегрируется через модуль hashivault или community-роль ansible-role-hashicorp-vault.
• AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: Для облачных стендов использование native-сервисов — оптимальный выбор.
• CyberArk, Thycotic и другие коммерческие решения.

# Пример использования community модуля для HashiCorp Vault (требуется hvac)
- name: Get database password from Vault
  hashivault_secret:
    url: "https://vault.company.com:8200"
    token: "{{ vault_auth_token }}"  # Этот токен тоже должен быть защищен!
    secret: "stand/prod/database"
    key: "password"
  register: vault_secret

- name: Use the secret in configuration
  template:
    src: db_config.j2
    dest: /app/config/database.conf
  vars:
    db_password: "{{ vault_secret.secret.password }}"

Ключевое преимущество: Секреты централизовано управляются, можно устанавливать политики TTL (время жизни), автоматически ротировать и иметь детальный аудит доступа.

3. Использование переменных окружения (Environment Variables)

Подход хорошо работает для реквизитов, которые уже управляются через окружение (например, в Docker или Kubernetes). Ansible может читать переменные окружения на контрол-хосте или на целевых хостах.

- name: Read API token from environment variable on control host
  set_fact:
    api_token: "{{ lookup('env', 'STAND_API_TOKEN') }}"

- name: Alternatively, use facts from target host (если секрет уже там)
  debug:
    msg: "Password is {{ ansible_env.SOME_SECRET_VAR }}"

Этот метод часто комбинируется с предыдущим: система управления секретами (например, Vault) инжектирует секреты в окружение контейнера перед запуском Ansible.

4. Динамические инвентари (Dynamic Inventory) с реквизитами

Инвентарь (inventory) — это естественное место для хосто-специфичных данных. Можно использовать динамический инвентарь, который возвращает не только список хостов, но и их переменные, включая реквизиты. Например, скрипт, который обращается к CMDB или облачной метаданной.

#!/usr/bin/env python3
# Пример скрипта динамического инвентаря, получающего данные из внешнего API
import json
import requests
from some_secret_manager import get_secret_for_host

def main():
    hosts = ['stand-web-01', 'stand-db-01']
    inventory = {'_meta': {'hostvars': {}}}
    for host in hosts:
        inventory['stand'] = {'hosts': hosts}
        inventory['_meta']['hostvars'][host] = {
            'ansible_host': '10.10.1.5',
            'db_admin_pass': get_secret_for_host(host, 'db_pass')  # Секрет получается здесь
        }
    print(json.dumps(inventory))

if __name__ == '__main__':
    main()

Рекомендуемая архитектура для Production стендов

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

1. Основные реквизиты стенда (пароли БД, токены API, SSH ключи для служебных пользователей) хранить в HashiCorp Vault (или аналоги). Ansible получает их напрямую через модули во время выполнения.
2. Конфигурационные данные без секретов (версии пакетов, порты, пути) хранить в обычных переменных Ansible, возможно, в git репозитории.
3. Реквизиты для доступа Ansible к самим хостам (SSH/winrm пароли или ключи) управлять либо через vault-шифрованный инвентарь, либо (лучше!) через статичные SSH ключи, развернутые на контрол хосте и не требующие передачи пароля в playbook. Для этого часто используется ansible_ssh_private_key_file в инвентаре.

Итог: Playbook должен быть текстом, свободным от секретов. Реквизиты стенда должны поступать из защищенного внешнего источника — специализированного Secrets Management решения — в момент выполнения. Это обеспечивает безопасность, возможность ротации секретов без изменения кода и соответствие требованиям compliance (PCI DSS, GDPR, etc.). Использование Ansible Vault является допустимым компромиссом для менее критичных сред, но для production-стендов внешние системы — это must-have.