Интеграция с Vault

Хранить пароли и токены в pillar-файлах в git — плохая практика: секреты попадают в историю репозитория, доступ к ним получает каждый, кто читает репо, а ротация превращается в коммиты. Интеграция с HashiCorp Vault выносит секреты во внешнее хранилище: в pillar и state-файлах остаются только пути к ним, а значения подтягиваются в момент рендеринга. После «Great Module Migration» модули Vault живут не в ядре Salt, а в community-расширении saltext-vault (организация salt-extensions на GitHub) — ставится оно через salt-pip install saltext-vault на мастер и, при необходимости локальных вызовов, на миньоны. Ключевая особенность интеграции: мастер выступает брокером аутентификации, и миньонам не нужно раздавать собственные долгоживущие токены Vault.

Как это работает

В конфиге мастера описывается подключение — адрес сервера Vault и способ аутентификации (token или AppRole). Дальше есть несколько путей доставки секретов. Ext pillar: строка - vault: path=secret/salt в ext_pillar монтирует секреты прямо в pillar миньона — states получают их как обычные pillar-значения. Execution-модуль: salt '*' vault.read_secret secret/myapp или в Jinja внутри SLS — {{ salt['vault'].read_secret('secret/myapp') }}. SDB-интерфейс позволяет ссылаться на секреты строками вида sdb://myvault/... в конфигах. Когда миньон вызывает vault.read_secret, он не идёт в Vault со своим постоянным токеном — он запрашивает у мастера временные учётные данные, а мастер выписывает их через свою авторизацию, применяя политики по шаблонам (в путях политик можно использовать minion id и grains). Так права каждого миньона в Vault ограничиваются его ролью, а компрометация одного узла не раскрывает чужие секреты.

Когда применять

Vault-интеграция оправдана, когда секретов много, они ротируются и к ним применяются требования аудита: Vault даёт версионирование KV, точечные политики и журнал доступа, чего pillar сам по себе не умеет. Типовые сценарии — пароли БД для конфигов приложений, TLS-ключи, токены внешних API. Она же снимает проблему «pillar в git»: репозиторий хранит только пути. Если же секретов немного и отдельный сервис поднимать не хочется, начните с малого — pillar с ограничением доступа по minion id уже сильно лучше секретов в state-файлах, а на Vault переедете, когда появится реальная потребность. Помните и о цене: Vault — это ещё один критичный сервис, который нужно резервировать, распечатывать (unseal) и мониторить; если он недоступен, рендеринг pillar и highstate с секретами начнёт падать.

Типичные ошибки

Частая ошибка — выдать мастеру root-токен Vault «чтобы заработало»: с шаблонными политиками мастер должен уметь выписывать только узкие права по ролям, root-токен превращает его в единую точку компрометации всех секретов. Вторая — секреты в pillar через ext_pillar без понимания кеширования: pillar кешируется на мастере, и ротация секрета в Vault не попадёт на миньон до обновления pillar (saltutil.refresh_pillar). Третья — вызовы vault.read_secret в Jinja внутри часто применяемых states: каждый рендер — поход в Vault, при большом парке это заметная нагрузка на него. Четвёртая — забыть, что после миграции модулей интеграция не входит в ядро: на свежем Salt без установленного saltext-vault функции просто отсутствуют, и это выглядит как «Salt сломался», хотя нужно лишь доставить расширение.

Связанные понятия

• Секреты в pillar
• Внешние pillar
• Salt extensions
• Безопасность