ACL и peer-коммуникация

По умолчанию командовать миньонами может только root на мастере — модель «всё или ничего». В реальной команде это неудобно: дежурному нужно уметь рестартить сервисы, релиз-инженеру — запускать state.apply на своём сегменте, и никому из них не нужен полный root. Для этого в конфигурации мастера есть два механизма. publisher_acl выдаёт локальным пользователям мастера ограниченный набор функций на ограниченном множестве миньонов. Интерфейс peer решает другую задачу: он разрешает самим миньонам вызывать функции на других миньонах через мастер — основа работы Salt Mine и сценариев, где, например, балансировщик должен опросить бэкенды.

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

Оба механизма настраиваются в конфиге мастера (/etc/salt/master или drop-in в master.d/). publisher_acl — это словарь «пользователь → таргет → список функций», значения поддерживают регулярные выражения:

publisher_acl:
  deploy:
    - 'web*':
        - test.ping
        - state.apply

Пользователь deploy сможет выполнить salt 'web*' state.apply, но получит отказ на cmd.run или на таргет db*. Проверка происходит на мастере в момент публикации задания. Дополнительно publisher_acl_blacklist запрещает опасные функции даже разрешённым пользователям. peer устроен зеркально, только субъект — миньон:

peer:
  'lb01':
    - network.ip_addrs

Теперь миньон lb01 может через execution-модуль publish выполнить salt-call publish.publish 'web*' network.ip_addrs: запрос уходит на мастер, тот проверяет его по peer-правилам и публикует от имени миньона. Есть и peer_run — аналогичное разрешение миньонам запускать runner'ы на мастере.

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

publisher_acl — правильный ответ, когда несколько человек или сервисных аккаунтов работают с одного мастера и им нужны разные полномочия: дежурная смена получает service.* и test.*, деплой-пользователь CI — state.apply на свой кластер. Это проще, чем полноценный eauth, потому что не требует внешнего бэкенда — достаточно локальных unix-пользователей. Если же нужен вход по корпоративным учёткам (LDAP) или доступ через salt-api — берите external_auth, синтаксис правил там тот же. peer включайте точечно и только когда без него нельзя: типовые случаи — mine.get для обмена данными между миньонами и оркестровки, где узел должен узнать адреса соседей. Широкий peer вида '*': [.*] означает, что любой скомпрометированный миньон командует всем парком.

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

Главная — считать publisher_acl полноценной защитой при разрешённых опасных функциях: cmd.run, file.write или state.single дают эскалацию до root на миньоне, а значит и на мастере, если он таргетируется. Разрешайте узкие функции, а не «всё кроме плохого». Вторая — забыть про права файловой системы: пользователю из ACL нужен доступ на чтение/запись к сокетам и кешу мастера, иначе команды падают с невнятными ошибками прав — hardening-гайд описывает нужные права. Третья — регулярки в таргетах: правило web* — это glob, а 'web.*' в ACL трактуется как regex; перепутав, вы откроете лишние машины. Четвёртая — включённый «на минутку» широкий peer, который остаётся навсегда и превращает один взломанный миньон в точку управления всеми.

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

• Безопасность
• Внешняя аутентификация (eauth)
• Salt Mine
• Конфигурация master
• Таргетинг миньонов