Внешняя аутентификация (eauth)

Тема дорожной карты · SaltStack

Система внешней аутентификации (eauth) позволяет запускать команды Salt не от root на мастере, а от именованных пользователей, которых проверяет внешний бэкенд — PAM, LDAP и другие. Это ответ на два вопроса сразу: «как дать команде доступ к Salt без раздачи root на мастере» и «кто именно запустил вчерашний state.apply на прод». Кроме интерактивной работы, eauth — обязательное условие для salt-api: REST-интерфейс аутентифицирует запросы именно через eauth, так что без него не будет ни интеграций, ни веб-хуков. Правила авторизации используют тот же синтаксис «таргет → функции», что и publisher_acl, поэтому переход от локальных ACL к eauth почти бесплатный.

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

В конфиге мастера описывается блок external_auth: бэкенд, пользователи или группы (суффикс %) и их права:

external_auth:
  pam:
    ops%:
      - 'web*':
          - test.ping
          - service.restart
      - '@runner':
          - jobs.list_jobs

Специальные ключи @runner, @wheel и @jobs открывают доступ к runner'ам, wheel-модулям (управление ключами) и истории заданий. Запуск с аутентификацией: salt -a pam 'web*' test.ping — клиент спросит логин и пароль, мастер проверит их через PAM и сверит запрос с правилами. Чтобы не вводить пароль на каждую команду, выпускается токен: salt -T -a pam ... — он сохраняется и подставляется автоматически до истечения срока. Бэкенд pam проверяет локальных пользователей системы (а через PAM-стек — что угодно, вплоть до sssd с доменом), бэкенд ldap ходит в каталог напрямую и умеет авторизацию по группам LDAP. salt-api принимает те же логин/пароль/бэкенд в запросе /login и возвращает токен для последующих вызовов.

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

Включайте eauth, как только с мастером работает больше одного человека: именованные пользователи дают аудит (в логах и job cache видно инициатора), а группы — управление доступом через существующий каталог. PAM — самый простой старт: работает из коробки с локальными пользователями и с доменной интеграцией через sssd. LDAP выбирают, когда права должны следовать за членством в группах каталога без создания локальных учёток. Для автоматизации (CI, ChatOps, порталы самообслуживания) eauth безальтернативен — salt-api без него не аутентифицирует никого. Если же весь доступ сводится к паре локальных пользователей на самом мастере и API не нужен, достаточно более простого publisher_acl.

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

Первая — широкие права «на посмотреть»: правило '*': [.*] для группы ops превращает каждого её участника в root всего парка; выдавайте конкретные функции и таргеты. Вторая — незашифрованный канал до salt-api: логины и пароли уходят открытым текстом, TLS обязателен. Третья — забытые токены: выпущенный токен живёт до истечения срока независимо от смены пароля пользователя, это нужно учитывать при офбординге. Четвёртая — PAM-бэкенд и сервис без прав: демон мастера должен иметь возможность читать PAM-стек, при запуске от непривилегированного пользователя аутентификация тихо ломается. Пятая — путаница между аутентификацией и авторизацией: успешный вход через LDAP не даёт прав сам по себе, права определяет только блок правил в external_auth.

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

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

Проверить знания (2)

Загрузка вопросов…