Ключи и 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.

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

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

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

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

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