Секреты в pillar

Pillar решает половину проблемы секретов: адресная раздача гарантирует, что пароль БД получит только миньон базы, а не весь парк. Но вторая половина остаётся: на диске мастера и — что хуже — в git-репозитории pillar-файлы лежат открытым текстом, вместе со всей историей изменений. Штатный ответ Salt — GPG-renderer: значения шифруются публичным ключом GPG и в таком виде живут в репозитории, а мастер расшифровывает их своим приватным ключом в момент рендеринга pillar. Дальше действует обычная модель pillar: расшифрованное значение уходит по шифрованному каналу только целевому миньону. Альтернативный путь — вообще не хранить секреты в файлах, а подтягивать их из внешней системы (например, Vault) через external pillar; тогда GPG не нужен, но появляется зависимость от доступности хранилища.

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

На мастере создаётся отдельный GPG-keyring, по умолчанию в /etc/salt/gpgkeys (путь настраивается опцией gpg_keydir); приватный ключ должен быть без passphrase, потому что расшифровка идёт неинтерактивно в процессе мастера. Значение шифруется на любой машине, где есть публичный ключ: echo -n 'S3cret!' | gpg --armor --batch --encrypt -r <key-id> — и получившийся блок -----BEGIN PGP MESSAGE----- вставляется в pillar-файл как обычное значение YAML (многострочный блок через |). Чтобы мастер понял, что файл нужно прогнать через расшифровку, в первой строке SLS указывается конвейер рендереров: #!yaml|gpg или #!jinja|yaml|gpg. При компиляции pillar мастер рендерит Jinja и YAML, затем GPG-renderer обходит структуру и заменяет каждый PGP-блок расшифрованным значением. Миньоны о GPG не знают ничего — им приезжает уже открытый текст, ключи нужны только мастеру.

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

GPG-pillar — правильный выбор, когда секретов относительно немного и команда хочет держать их в том же git-репозитории, что и остальной pillar: ревью через PR, история изменений, никакой дополнительной инфраструктуры. Это типовой вариант для небольших и средних инсталляций. Внешнее хранилище (Vault и аналоги через external pillar или execution-модуль) выигрывает, когда секретов много, нужны ротация, аудит доступа и выдача коротко живущих учётных данных — ценой отдельного сервиса, который надо развернуть и поддерживать. Держать секреты в pillar открытым текстом допустимо разве что в лаборатории без git. В любом варианте помните: pillar защищает доставку, но не то, что происходит с секретом дальше — например, file.managed, записавший пароль в конфиг, оставит его в кэше миньона.

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

Самая обидная — закоммитить секрет открытым текстом «на минутку»: из истории git он уже не исчезнет, придётся ротировать. Частая техническая ошибка — забыть shebang #!yaml|gpg в SLS: PGP-блок уедет миньону как есть, буквальной строкой, и это легко не заметить. Шифрование с -r на неправильный ключ даёт блок, который мастер не может расшифровать. Потеря приватного ключа мастера означает потерю всех зашифрованных значений — ключ нужно бэкапить так же строго, как и сами секреты. Наконец, включённый на мастере pillar_cache сохраняет уже расшифрованный pillar на диск — проверьте настройки кэша, прежде чем включать его в окружении с GPG-секретами.

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

• Pillar
• Pillar top file
• Внешние pillar
• Интеграция с Vault
• Транспорт и шифрование