Интеграция Sudoers и FreeIPA: централизованное управление sudo

Sudo можно централизованно управлять через FreeIPA: настроить глобальный доступ к sudo для группы или ограничить права по хостам и конкретным командам. В статье описаны две практические сценария с пошаговыми командами ipa, настройкой SSSD на клиенте, HBAC и группами команд sudo, а также проверкой и плейбуком для развертывания.

Введение

Sudo — это утилита, позволяющая получать права root или администратора на Linux/Unix. На большинстве дистрибутивов Linux sudo установлена по умолчанию; управление тем, кто и какие команды может выполнять как root, производится через файл /etc/sudoers или через централизованные решения. В этой статье рассматривается интеграция Sudoers с FreeIPA для централизованного управления привилегиями.

FreeIPA включает ряд средств, упрощающих работу администратора: каталог пользователей, управление хостами, HBAC (Host-Based Access Control) и встроенную поддержку sudo. С помощью FreeIPA можно дать пользователям полный доступ sudo на всех клиентах или ограничить права конкретными командами и хост-группами.

Цели этой инструкции:

• Показать настройку общего sudo для пользователей FreeIPA (полный root-доступ).
• Показать настройку ограниченного sudo (только конкретные команды на конкретных хостах).
• Рассказать про использование утилиты ipa для управления пользователями, группами, HBAC, sudo-правилами и группами команд.
• Пояснить настройку SSSD на клиенте для поддержки sudo через FreeIPA.

Важно

• Перед началом убедитесь, что FreeIPA-сервер установлен и настроен, и клиенты присоединены к домену FreeIPA.
• Для выполнения команд на сервере и клиентах потребуется пользователь с правами администратора FreeIPA и локальный не-root пользователь с sudo или root-правами на машинах.

Требования

Нужно иметь установленный и настроенный FreeIPA-сервер и как минимум один клиент, присоединённый к FreeIPA. Подробные инструкции по установке FreeIPA на Debian/Ubuntu/Rocky Linux можно найти в специфицированных руководствах (см. ссылки в исходной документации).

Пример окружения, используемого в статье:

Hostname            IP Address      Used as
--------------------------------------------------
ipa.hwdomain.lan    192.168.5.20    FreeIPA Server
client.hwdomain.lan 192.168.5.75    FreeIPA Client

Если эти условия выполнены, можно приступать к интеграции Sudoers и FreeIPA.

Раздел 1 — Разрешить пользователям FreeIPA полноценно выполнять sudo

В этом сценарии мы дадим существующему пользователю FreeIPA (rocky) возможность выполнять sudo на всех клиентах и получать права root. План действий:

• Проверить наличие пользователя и сетевое подключение
• Включить поддержку sudo в SSSD на клиенте
• Создать группу и правило sudo в FreeIPA
• Проверить интеграцию

Проверка пользователя FreeIPA и подключения

Сначала убедитесь, что пользователь rocky существует в FreeIPA:

ipa user-find rocky

Ожидается вывод: “1 user matched” — это подтверждает, что учетная запись существует.

Затем подключитесь по SSH к клиенту как этот пользователь, чтобы проверить, что он может войти на клиентскую машину:

ssh [email protected]

Введите пароль пользователя rocky и после входа выполните:

whoami
id

Попытка выполнить sudo должна сейчас завершиться ошибкой, так как пользователь ещё не имеет sudo-привилегий:

sudo su

Ожидаемая ошибка: “rocky is not in the sudoers file. This incident will be reported.”

Включение поддержки sudo в SSSD на клиенте

SSSD (System Security Services Daemon) должен быть настроен, чтобы передавать sudo-политику от FreeIPA клиентам. На клиенте выполните:

sudo authselect enable-feature with-sudo
sudo systemctl restart sssd
sudo systemctl status sssd

В выводе systemctl status sssd ожидается “active (running)”.

Команда

authselect current

покажет активные функции; среди них должен быть with-sudo:

Создание sudo-правила в FreeIPA

Логика: создаём группу sysadmin, создаём sudo-правило sysadmin_sudo, привязываем к нему группу и приписываем пользователя rocky в группу.

Создание группы:

ipa group-add --desc='Sysadmin Team' sysadmin
ipa group-find sysadmin

Ожидается сообщение “Added group \”sysadmin\”” и подтверждение наличия группы.

Создание sudo-правила, разрешающего выполнение любых команд от имени любых пользователей/групп на всех хостах:

ipa sudorule-add sysadmin_sudo \
    --hostcat=all --runasusercat=all --runasgroupcat=all --cmdcat=all

Вывод должен содержать: “Added Sudo Rule \”sysadmin_sudo\””.

Добавим группу в правило:

ipa sudorule-add-user sysadmin_sudo --group sysadmin

Проверка правила:

ipa sudorule-show sysadmin_sudo

В секции User Groups вы должны увидеть sysadmin.

Добавим пользователя rocky в группу:

ipa group-add-member --user=rocky sysadmin
ipa group-show sysadmin

В выводе группы появится член rocky.

Проверка интеграции sudoers с FreeIPA

Теперь подключитесь к клиенту как rocky и попробуйте выполнить sudo:

ssh [email protected]
id
whoami
sudo id
sudo su
id
whoami

При успешной операции prompt сменится на root@hostname и id/whoami покажут root.

Итог первого сценария: все пользователи в группе sysadmin получили возможность выполнять sudo на всех хостах.

Раздел 2 — Разрешить пользователям FreeIPA выполнять sudo только для конкретных команд

Задача: создать нового пользователя max, группу systemadmin, хост-группу appserver, HBAC-правило, sudo-правило и группу sudo-команд, чтобы пользователь max мог подключаться только к выбранным хостам и выполнять только определённые команды управления LEMP (Nginx, PHP-FPM, MariaDB).

План действий:

• Создать пользователя и группу
• Создать хост-группу и добавить в неё клиент
• Отключить дефолтное HBAC allow_all и настроить кастомное HBAC
• Создать sudo-правило, группу команд и привязать их
• Проверить работу на клиенте

Создание пользователя и группы

Создадим пользователя max и группу systemadmin, затем добавим max в группу.

ipa user-add max --first=Max --last=Rods --password
ipa user-find max

ipa group-add --desc='System Admin Team' systemadmin
ipa group-add-member --user=max systemadmin
ipa group-show systemadmin

После входа ssh убедитесь, что пользователь может зайти и сменить пароль (если prompt требует):

ssh [email protected]
id
whoami

Создание хост-группы

Проверим список хостов и создадим хост-группу appserver, добавив в неё client.hwdomain.lan:

ipa host-find
ipa hostgroup-add appserver
ipa hostgroup-add-member appserver --hosts=client.hwdomain.lan
ipa hostgroup-show appserver

Создание HBAC-правила

По умолчанию в FreeIPA есть правило allow_all, которое позволяет всем логинам. Для более точного управления его стоит отключить и создать явное правило.

Отключение дефолтного правила:

ipa hbacrule-disable allow_all
ipa hbacrule-show allow_all

Вы увидите, что Enabled = false.

Создадим новое правило operation_admin и добавим в него хост-группу appserver и группу systemadmin (пользователей):

ipa hbacrule-add operation_admin
ipa hbacrule-add-host operation_admin --hostgroup appserver
ipa hbacrule-add-user operation_admin --group systemadmin

Добавим сервисы, которым разрешено использоваться в рамках правила: sshd, sudo и su-l (в зависимости от сервиса на клиенте):

ipa hbacrule-add-service operation_admin --hbacsvcs=sshd
ipa hbacrule-add-service operation_admin --hbacsvcs=sudo --hbacsvcs=su-l
ipa hbacrule-show operation_admin

После этого пользователь rocky (если не в systemadmin) не сможет подключаться к client.hwdomain.lan, а max сможет, так как он член systemadmin.

Проверка логина как rocky и max:

ssh [email protected]
ssh [email protected]

Создание sudo-правила

Создадим sudo-правило systemadmin_sudo, которое будет применяться только к пользователям/группам и хост-группам, без разрешения всех команд по умолчанию:

ipa sudorule-add systemadmin_sudo \
    --runasusercat=all --runasgroupcat=all

ipa sudorule-add-user systemadmin_sudo --group systemadmin
ipa sudorule-add-host systemadmin_sudo --hostgroup appserver
ipa sudorule-show systemadmin_sudo

Создание группы sudo-команд

Чтобы ограничить набор команд, используйте sudocmd и sudocmdgroup.

Добавим команды для управления LEMP-сервисами (systemctl start/restart для nginx, php-fpm, mariadb):

ipa sudocmd-add "/usr/bin/systemctl start nginx"
ipa sudocmd-add "/usr/bin/systemctl restart nginx"

ipa sudocmd-add "/usr/bin/systemctl start php-fpm"
ipa sudocmd-add "/usr/bin/systemctl restart php-fpm"

ipa sudocmd-add "/usr/bin/systemctl start mariadb"
ipa sudocmd-add "/usr/bin/systemctl restart mariadb"

Создадим группу команд и добавим в неё эти команды:

ipa sudocmdgroup-add systemadmin_cmds
ipa sudocmdgroup-add-member systemadmin_cmds \
    --sudocmds "/usr/bin/systemctl start nginx" \
    --sudocmds "/usr/bin/systemctl restart nginx" \
    --sudocmds "/usr/bin/systemctl start php-fpm" \
    --sudocmds "/usr/bin/systemctl restart php-fpm" \
    --sudocmds "/usr/bin/systemctl start mariadb" \
    --sudocmds "/usr/bin/systemctl restart mariadb"

Ожидаемый вывод: группа создана и добавлены 6 команд.

Привяжем группу команд к sudo-правилу:

ipa sudorule-add-allow-command systemadmin_sudo --sudocmdgroups systemadmin_cmds

Проверка интеграции sudo и FreeIPA

Войдите на client.hwdomain.lan как max и попробуйте перезапустить сервисы LEMP:

ssh [email protected]
id
whoami
sudo /usr/bin/systemctl restart nginx
sudo /usr/bin/systemctl restart php-fpm
sudo /usr/bin/systemctl restart mariadb

Эти команды должны выполниться успешно. Попытка выполнить запрещённую команду (например systemctl stop) должна привести к отказу:

sudo /usr/bin/systemctl stop nginx

Ожидаемый вывод: “Sorry, user max is not allowed to execute … as root on client.hwdomain.lan”

Итог сценария: пользователь max получил ограниченные sudo-привилегии только для управления LEMP на хостах группы appserver.

Практические заметки и рекомендации

Важно:

• После изменения политики sudo и HBAC дождитесь распространения обновлений через SSSD и кэши клиенов; иногда требуется очистить кэш (sudo sss_cache -E) или перезапустить sssd.
• Проверяйте привязки: правило HBAC должно разрешать SSH, иначе даже корректное sudo-правило не поможет.
• Для диагностики используйте journalctl -u sssd и /var/log/secure (или аналог) на клиенте, а также ipa hbacrule-show/sudorule-show для проверки связей.

Когда такая схема не подходит

• В средах без централизованной сети (offline) или при строгом требовании к аудитам на уровне аппаратных HSM/TPM централизованное решение может быть нежелательно.
• Если требуется тонкая интеграция с внешними системами контроля доступа (например, нестандартные PAM-модули), может потребоваться дополнительная доработка.

Альтернативные подходы

• Управление sudo через конфигурационные менеджеры (Ansible/Chef/Puppet) и правки /etc/sudoers.d — удобно для декларативного управления, но менее гибко для динамических изменений.
• LDAP-only или AD (Active Directory) интеграция для тех, кто уже использует AD; FreeIPA даёт удобный стек, но в смешанных средах может потребоваться мост.

Ментальные модели (heuristics)

• RBAC поверх HBAC: сначала определите, кто (роли/группы) и где (хосты/хост-группы) — затем какие действия (sudocmdgroups).
• Principle of least privilege: выдавайте минимальный набор команд и прав, необходимый для роли.
• Разделяйте доступы: отдельные группы для админов, операторов, разработчиков.

Факт-бокс (ключевые элементы)

• FreeIPA: каталог, HBAC, sudorule, sudocmdgroup — все ключевые примитивы.
• SSSD: клиентский компонент, пересылает sudo-политику и данные пользователей.
• authselect: инструмент для управления профилями аутентификации; нужна функция with-sudo для поддержки sudo через SSSD.

План внедрения (мини-roadmap)

1. Подготовка окружения: протестировать FreeIPA и клиента в тестовой сети.
2. Включить with-sudo на клиенте и перезапустить sssd.
3. Создать базовые группы (sysadmin, systemadmin) и тестовых пользователей.
4. Создать HBAC-правила и обязательно протестировать доступ.
5. Создать sudo-правила и группы команд, протестировать выполнение и отказ.
6. Документировать и ввести в продакшн после ревью.

Плейбук — быстрый SOP для интеграции (сокращённый)

• На клиенте:

  • sudo authselect enable-feature with-sudo
  • sudo systemctl restart sssd
  • проверить authselect current

• На FreeIPA-сервере:

  • ipa group-add …
  • ipa sudorule-add …
  • ipa sudorule-add-user …
  • ipa sudorule-add-host …
  • ipa sudorule-add-allow-command …

• Тестирование:

  • ssh как тестовый пользователь
  • sudo -l для проверки доступных команд
  • выполнить разрешённые команды, подтвердить отказ для запрещённых

Рольные чеклисты (role-based)

• Операторы (Operator):

  • Должны иметь sudo-доступ только к перезапуску релевантных сервисов
  • Проверяют sudo -l перед изменениями

• Системные администраторы (Sysadmin):

  • Имеют доступ к широкому набору команд, управляются через sysadmin_sudo
  • Отслеживают изменения правил в FreeIPA

• Безопасность/ревью (Security):

  • Проводит аудит списков sudo-прав каждые N недель
  • Проверяет логи доступа и сообщения PAM

Критерии приёмки

• Пользователь из группы sysadmin безошибочно получает root-доступ на целевых хостах.
• Пользователь max получает доступ только к заявленным systemctl-командам и получает отказ при попытке выполнить запретные команды.
• HBAC ограничивает доступ по хост-группам корректно.
• SSSD на клиентах в статусе active (running) и передаёт sudo-информацию.

Тестовые случаи (acceptance)

• TC1: rock

  • Предусловие: rock в группе sysadmin
  • Шаг: ssh [email protected]; sudo id
  • Ожидаемый результат: id показывает root

• TC2: max — разрешённая команда

  • Шаг: ssh [email protected]; sudo /usr/bin/systemctl restart nginx
  • Ожидаемый результат: команда выполняется успешно

• TC3: max — запрещённая команда

  • Шаг: sudo /usr/bin/systemctl stop nginx
  • Ожидаемый результат: отказ и сообщение о недоступности команды

Диагностика и отладка

• Просмотр логов SSSD на клиенте: journalctl -u sssd -b
• Очистка кэша SSSD: sudo sss_cache -E
• Проверка правил в FreeIPA: ipa sudorule-show, ipa hbacrule-show, ipa sudocmdgroup-show
• Проверка sudo-политики на клиенте: sudo -l

Модель риска и смягчения

• Риск: слишком широкие sudo-права (cmdcat=all) — смягчение: применять принцип least privilege и использовать sudocmdgroup.
• Риск: HBAC по ошибке блокирует доступ — смягчение: иметь аварийного администратора с локальным root-доступом на хосте.
• Риск: рассинхронизация SSSD — смягчение: мониторинг статуса sssd и alerting при падении.

Глоссарий (1 строка на термин)

• FreeIPA: интегрированный сервер идентификации для Linux.
• SSSD: агент для получения учётных записей и политик от FreeIPA на клиенте.
• HBAC: правила доступа пользователей к хостам и сервисам.
• sudorule: правило FreeIPA, описывающее, кто и где может использовать sudo.
• sudocmdgroup: группа команд sudo, применяемая к правилам.

Социальный предпросмотр (рекомендация OG)

OG title: Sudo + FreeIPA: централизованное управление sudo OG description: Как настроить централизованные sudo-права в FreeIPA: полные и ограниченные сценарии, HBAC, SSSD и примеры команд.

Короткое объявление (100–200 слов)

В этой заметке описывается пошаговая интеграция sudo и FreeIPA: от включения поддержки with-sudo в SSSD на клиенте до создания правил sudorule и групп команд sudocmdgroup в FreeIPA. Приведены два сценария: выдача полного sudo для группы администраторов и частичная выдача прав только для управления LEMP (Nginx, PHP-FPM, MariaDB) на выбранных хостах. Включён плейбук, рольные чеклисты, критерии приёмки и советы по отладке.

Резюме

• FreeIPA позволяет централизованно управлять sudo-привилегиями через sudorule и sudocmdgroup.
• SSSD на клиенте должен быть сконфигурирован с фичей with-sudo.
• HBAC управляет, кто и с каких хостов может подключаться; sudorule управляет, какие команды доступны через sudo.
• Тщательно тестируйте права в тестовой среде и применяйте принцип наименьших привилегий.

Ключевые материалы и команды собраны в теле статьи — используйте их как шаблон для внедрения в своей инфраструктуре.