Безопасность

Salt по определению умеет выполнять произвольные команды от root на всех серверах парка — компрометация мастера означает компрометацию всей инфраструктуры. Поэтому безопасность Salt — не тема «на потом», а часть базовой настройки. Модель угроз складывается из трёх слоёв: защита канала мастер–миньон (шифрование транспорта и доверие ключей), контроль того, кто и что может запускать через мастер (publisher_acl, eauth), и защита секретов, которые Salt раздаёт миньонам (pillar, внешние бэкенды вроде Vault). У проекта есть официальный hardening-гайд — его стоит прочитать целиком до вывода мастера в продакшен и возвращаться к нему после каждого мажорного обновления.

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

Мастер слушает два порта: 4505 (publish — рассылка команд) и 4506 (request/return — запросы миньонов и возврат результатов). Соединения всегда инициируют миньоны, поэтому на них входящие порты открывать не нужно, а файрвол мастера должен пускать на 4505/4506 только адреса миньонов. Полезная нагрузка шифруется AES-ключом, который мастер передаёт миньонам через обмен RSA-ключами: при первом подключении миньон присылает публичный ключ и до команды salt-key -a <id> не получает ничего. Именно поэтому автоприём ключей — дыра: чужой «миньон» получит pillar-данные, которые вы ему отрендерите. Ключи сверяют по отпечаткам — salt-key -f <id> на мастере против salt-call --local key.finger на миньоне. Дальше включаются слои авторизации: publisher_acl ограничивает локальных пользователей мастера, external_auth (PAM/LDAP) даёт именованный доступ операторам, peer дозирует общение миньонов между собой.

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

Минимум для любого продакшена: файрвол на 4505/4506, верификация отпечатков ключей (вручную или через заранее подложенные preseed-ключи), работа операторов через publisher_acl/eauth вместо общего root на мастере. Если Salt пользуются несколько человек — включайте external_auth, чтобы в логах и job cache было видно, кто именно запустил state.apply на прод. Секреты не кладите в state-файлы и не таргетируйте по grains: grains формирует сам миньон и может их подделать, поэтому критичные pillar-данные привязывайте к minion id, который подтверждён ключом. Для salt-api обязательны TLS и eauth — без них REST-интерфейс превращается в удалённый root на весь парк. Внешний бэкенд секретов (Vault через saltext-vault) убирает секреты из git-репозитория с pillar.

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

Классика — auto_accept: True, включённый «на время тестов» и доживший до продакшена. Вторая ошибка — выдача секретов по grains-таргетингу: скомпрометированный миньон объявляет себя чужой ролью и забирает чужие пароли. Третья — мастер, открытый портами в интернет без ограничений по адресам: любой может прислать ключ и засорять очередь приёма, а после ошибочного salt-key -A — читать pillar. Четвёртая — забытая эквивалентность прав: доступ на запись в file_roots или pillar (в том числе из CI-пайплайна) равен root на всех миньонах, поэтому репозиторий состояний и деплой-джобы защищают так же строго, как сам мастер. Наконец, старые непринятые и отозванные ключи копятся годами — периодический аудит salt-key -L должен быть рутиной.

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

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

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

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

Полезные ресурсы