Секреты в 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
• Транспорт и шифрование