Astra Linux 2.12: обновляем серверный парк и разбираемся с Podman, мандатным контролем и нашими ролями

Astra Linux 2.12 вышел с двумя заявленными улучшениями, которые нас интересовали больше всего: нативная поддержка Podman и переработанная интеграция с Active Directory. Поводом для обновления стал плановый цикл сопровождения - мы вели несколько серверов на 2.8, и разрыв между версиями уже начинал сказываться на совместимости пакетов. Решили обновиться и заодно зафиксировать, что реально изменилось, а не что написано в release notes.

Мандатный контроль: стало строже, но предсказуемее

Первое, на что обратили внимание - поведение мандатного контроля доступа (MAC) в 2.12 стало заметно строже в отношении операций с файловой системой в пространстве пользователя. Несколько сервисов, которые на 2.8 работали без проблем под выделенными системными пользователями, после обновления упали при старте - именно на попытке открыть свой же лог-файл или конфиг.

Корень проблемы - изменение уровня мандатной метки по умолчанию для новых объектов файловой системы. В 2.12 объекты, созданные в процессе пакетной установки, получают метку выше, чем ожидает сервис, работающий под ограниченным контекстом. В 2.8 это проходило тихо, потому что там граница была мягче.

Решение прямолинейное: явное выставление меток через pdpl-file для каталогов, которые сервис использует. В ролях пришлось добавить задачи:

pdpl-file -R 0:0 /var/lib/<service-name>
pdpl-file 0:0 /etc/<service-name>/<config>.conf

Неприятно, но не катастрофа. Главное - делать это до первого старта сервиса, иначе он создаёт объекты с неправильными метками и потом всё равно падает.

Ещё один момент с MAC - ролевое разделение при sudo. В 2.8 часть наших ролей использовала sudo-команды через Ansible без учёта мандатных меток сессии. В 2.12 sudo наследует мандатную метку вызывающего пользователя, и если она не соответствует тому, что нужно для операции - получаем отказ. Пришлось пересматривать несколько задач, где sudo вызывался с контекстом непривилегированного пользователя для записи в системные каталоги.

Podman: наконец-то в пакетной базе нормально

Это, пожалуй, самое приятное изменение. В 2.8 Podman ставился через отдельный репозиторий, конфликтовал с рядом системных пакетов, а rootless-режим требовал ручной настройки kernel parameters и subuid/subgid. Сколько раз мы проходили этот путь на каждом новом хосте - не считали, но каждый раз было весело по-своему.

В 2.12 Podman идёт в составе базового репозитория и поставляется с предустановленными настройками под мандатную модель Astra. Rootless-режим работает сразу после apt install podman - subuid и subgid прописываются автоматически при установке пакета, необходимые параметры ядра включены в базовой конфигурации.

Что проверяли в Podman:

• Rootless-контейнеры - запускаются без дополнительных телодвижений. Тестировали на нескольких образах, включая наши внутренние сервисные образы на базе УЦ-совместимых сертификатов.
• Podman socket под systemd - podman.socket активируется и работает, что важно для совместимости с некоторыми инструментами, которые ожидают Docker-совместимый API.
• Мандатный контроль и контейнеры - вот здесь интересно. Контейнер получает мандатную метку хоста, и если сервис внутри пытается создать файлы с меткой выше, чем разрешено процессу - получает отказ. Это не баг, это так и должно работать, но несколько наших образов пришлось пересобрать с учётом этого ограничения.

Наши Ansible-роли для Podman, которые мы писали под RED OS 9.0 (о том, как это шло, писали раньше), на Astra 2.12 прошли почти без изменений. Основная разница - добавился блок для выставления мандатных меток на каталоги монтирования томов.

Active Directory: интеграция стала менее болезненной

В 2.8 вход в домен через realm join регулярно приходилось чинить руками - чаще всего из-за несоответствия версий Kerberos и неочевидных конфликтов между sssd и winbind. В 2.12 заявлена переработанная интеграция, и на нашей практике это подтверждается.

realm join прошёл на всех тестовых хостах с первой попытки, sssd завёлся корректно, групповые политики применились. Для наших задач это важно, потому что часть управляемой инфраструктуры стоит в доменах с Windows-контроллерами, и каждый раз, когда при смене версии ОС надо было чинить AD-интеграцию вручную, это съедало несколько часов.

Пока отмечаем: работает лучше, чем в 2.8. Насколько это устойчиво под нагрузкой и при смене контроллеров домена - посмотрим по ходу сопровождения.

Ansible-роли: итоговый счёт

Прошлись по всему стеку ролей, который используем для Astra-хостов. Из приблизительно двух десятков ролей:

• Большинство прошли без изменений - пакетный менеджмент, systemd, базовая конфигурация сети.
• Несколько ролей потребовали добавления задач для управления мандатными метками - это предсказуемо.
• Одна роль (для деплоя сервиса, который создаёт файлы от имени разных пользователей) потребовала архитектурной правки: пришлось явно разделить операции по созданию объектов ФС и по запуску сервиса, чтобы контроль меток работал корректно.
• Роли для Podman обновились минимально - только добавили метки на каталоги томов.

Интеграцию с Ansible AWX проверяли параллельно - AWX управляет запуском ролей, и здесь никаких проблем с Astra 2.12 не обнаружили. Inventory-переменные те же, execution environment не менялся.

Где мы сейчас

Обновление идёт поэтапно: сначала закрыли тестовый контур, потом прошлись по хостам с некритичными сервисами. Продакшн-серверы с максимально чувствительными данными - следующий шаг, и там отдельно проверим поведение MAC под реальной нагрузкой.

Общее впечатление: 2.12 - это заметный прогресс. Podman стал нормальным инструментом, а не пазлом. AD-интеграция перестала быть источником сюрпризов. MAC стал строже, но стал хотя бы понятнее - в 2.8 его поведение местами угадывалось, а не документировалось.

Managed-сопровождение инфраструктуры на Astra продолжает требовать внимания к специфике мандатной модели - это не то, что решается один раз при установке. Но 2.12 сделал эту работу чуть менее болезненной.