Ansible Vault и no_log: где секреты остаются после расшифровки

Секрет перенесли в Ansible Vault, затем запустили playbook с --diff и увидели его в журнале изменения конфигурации. Противоречия нет: Vault защищает зашифрованное содержимое при хранении, а во время выполнения Ansible должен получить исходное значение. Дальше оно может попасть в результат задачи, template, аргументы процесса или лог приложения.

Поэтому защищать нужно несколько точек. Vault — файл или значение в репозитории. No_log — чувствительный вывод определённой задачи. Права файла — доступ к конфигурации на управляемой машине. Эти настройки дополняют друг друга и не включаются автоматически одна из другой.

Создадим зашифрованный файл без секрета в аргументах

На стенде выполните команду создания Vault-файла. Она запросит пароль и откроет редактор; введите фиктивный app_token, чтобы проверить весь путь без рабочего credential.

ansible-vault create secrets.yml

Содержимое до шифрования должно быть YAML вида app_token: demo-token-for-training. Сохранённый secrets.yml начинается с заголовка Ansible Vault и содержит шифротекст. Пароль Vault храните отдельно от репозитория: файл с паролем рядом с шифротекстом в Git устраняет полезную границу доступа.

Редактор способен оставлять swap, backup и временные файлы. Для рабочей процедуры проверьте его поведение и правила доступа к каталогу. Команда create не делает любые промежуточные копии автоматически безопасными.

Расшифруем значение только для нужной задачи

Создайте app.conf.j2 с одной строкой token={{ app_token }}. Следующий playbook записывает её в отдельный локальный каталог и выводит только статус успешного выполнения, без значения.

- name: Render a protected application file
  hosts: localhost
  connection: local
  gather_facts: false
  vars_files:
    - secrets.yml
  tasks:
    - name: Prepare private directory
      ansible.builtin.file:
        path: /tmp/latorn-vault-demo
        state: directory
        mode: '0700'
    - name: Write application credentials
      ansible.builtin.template:
        src: app.conf.j2
        dest: /tmp/latorn-vault-demo/app.conf
        mode: '0600'
      no_log: true
      diff: false
    - name: Report completion without the token
      ansible.builtin.debug:
        msg: Application credential file has been rendered

ansible-playbook -i localhost, demo.yml --ask-vault-pass

В обычном выводе чувствительная template-задача должна быть скрыта, а готовый файл доступен только владельцу. Сообщение debug не содержит app_token и не сериализует результат template. Сам app.conf теперь хранит открытый токен, потому что именно такой файл ожидает приложение. Его нельзя считать зашифрованным только из-за происхождения переменной из Vault.

No_log действует на конкретный вывод

No_log ограничивает стандартное отображение чувствительной задачи. Но следующая debug с var: app_token снова раскроет значение, если её отдельно не защитить. Аналогично register сохраняет данные в памяти и позволяет последующей задаче вывести их. Не печатайте целиком результаты, которые могли содержать секреты.

Diff: false явно запрещает сравнение содержимого для этой задачи при --diff. Для несекретной части конфигурации diff полезен, поэтому обычно проще защитить конкретные чувствительные задачи, а не полностью лишать диагностики весь playbook.

Где ещё остаются копии

Приложение может записывать конфигурацию в собственный лог, crash dump или backup. Команда с токеном в аргументах способна показать его в списке процессов. No_log не меняет поведение внешней программы и не шифрует её файлы. Выбирайте способ передачи секрета, который поддерживает приложение, и проверяйте конечный журнал на стендовых значениях.

Пользователь с правом прочитать app.conf получает токен независимо от доступа к Vault. Поэтому определите владельца процесса и права назначения; в реальном сервисе это может быть отдельная учётная запись приложения, а не пользователь локального примера. Удалённые резервные копии должны соблюдать ту же политику.

Проверим защиту фиктивным токеном

Запустите стенд с подробным выводом и diff только на учебном значении. Убедитесь, что токен не появляется в стандартном журнале, а приложение получает ожидаемый файл. Не включайте внутренний ANSIBLE_DEBUG для рабочего запуска: отладочные пути могут раскрыть секреты вопреки обычному no_log.

Vault решает хранение, но пароль расшифрования тоже требует выдачи и ротации. Для CI определите, откуда он приходит и кто может запускать код с этим доступом. После реальной утечки недостаточно заново зашифровать YAML: нужно заменить сам credential и разобраться с доступными копиями журналов и файлов.

Ещё по теме

• delegate_to и run_once в Ansible: где выполняется задача и сколько раз
• Ansible --tags пропускает нужные задачи: include_tasks и import_tasks

Продолжить изучение

Хотите собрать настройку серверов в повторяемый процесс? Inventory, роли, шаблоны и обновление сервисов входят в программу «Ansible: автоматизация инфраструктуры».