Ключи и salt-key

Доверие между мастером и миньонами в Salt основано на RSA-ключах. При первом запуске миньон генерирует пару ключей и отправляет публичный ключ мастеру. Пока администратор не примет этот ключ, мастер не выполнит на миньоне ни одной команды. Принятые ключи используются для защищённого обмена: команды и данные шифруются AES-ключом, который мастер раздаёт миньонам поверх RSA. Утилита salt-key на мастере — единственный штатный интерфейс для управления доверием: просмотр, приём, отклонение и удаление ключей. Это не формальность, а буквально периметр безопасности инфраструктуры: принятие чужого ключа означает впуск чужого хоста в парк и предоставление ему доступа к файловому серверу и pillar-данным, которые ему адресованы.

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

Ключи на мастере хранятся в /etc/salt/pki/master/, разложенные по статусам в каталоги: minions (принятые), minions_pre (ожидающие), minions_rejected (отклонённые), minions_denied (конфликтные). Команда salt-key -L показывает все ключи по спискам; salt-key -a web-01 принимает конкретный ключ, salt-key -A — все ожидающие, salt-key -r <id> отклоняет, salt-key -d <id> удаляет. Перед приёмом ключ стоит верифицировать: salt-key -f <id> печатает отпечаток ключа на мастере, а на самом миньоне тот же отпечаток даёт salt-call --local key.finger — совпадение подтверждает, что ключ пришёл именно с этой машины. Проверка работает и в обратную сторону: опция master_finger в конфигурации миньона фиксирует отпечаток ключа мастера, защищая миньона от подмены мастера.

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

Ручной приём с проверкой отпечатков — правильный режим для небольших и средних парков: минута работы на миньоне в обмен на гарантию, что в инфраструктуру не вошёл чужой хост. При автоматическом разворачивании машин ключевой поток тоже нужно автоматизировать — но контролируемо: через autosign_file с жёсткими ограничениями или реакцию на события, а не через глобальный auto_accept: True. salt-key -d — штатная часть жизненного цикла: удаляйте ключи выведенных из эксплуатации машин, иначе списки зарастают «мертвецами», а таргетинг по * продолжает ждать ответов от несуществующих миньонов. После пересоздания машины с тем же id старый ключ обязательно удаляется — иначе новый экземпляр не подключится.

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

Худшая практика — рефлекторный salt-key -A без сверки отпечатков: в этот момент любой, кто дотянулся до порта 4506 и назвался правдоподобным id, становится доверенным миньоном. Вторая ошибка — золотые образы с уже сгенерированными ключами: клоны поднимаются с одинаковой парой ключей и одинаковым id, и мастер видит «одного» миньона вместо десяти; ключи и minion_id надо вычищать из образа. Третья — после переустановки мастера миньоны отказываются подключаться, потому что закэшировали старый публичный ключ мастера: его нужно удалить из /etc/salt/pki/minion/ на каждом миньоне. Четвёртая — путать отклонение и удаление: отклонённый ключ остаётся лежать в minions_rejected и блокирует повторную регистрацию миньона с тем же id.

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

• Конфигурация minion
• Конфигурация master
• Транспорт и шифрование
• Безопасность
• Архитектура master–minion