RED OS 9.0 и КИИ: тестируем совместимость с Ansible, RPM и продакшн-сервисами

RED OS 9.0 вышел в сентябре с двумя заявленными приоритетами: нормальная поддержка контейнерных сред и обновлённая сборка ядра, ориентированная на требования для объектов КИИ. По меркам отечественных дистрибутивов - шаг заметный. Мы как раз прорабатываем миграцию нескольких продакшн-контуров с RHEL 9 на отечественную ОС, так что RED OS 9.0 попал в наш стенд в нужный момент.

Главный вопрос, который нас интересовал: насколько он совместим с тем, что у нас уже есть - Ansible-ролями, RPM-репозиториями и типовыми сервисами продакшн-контура. Не в теории «вот что написано в документации», а на практике.

Ansible-роли: где прошло, где нет

Основной объём автоматизации у нас написан под RHEL 8/9 и, в меньшей степени, под AlmaLinux. RED OS 9.0 объявляет совместимость с RHEL 9, и в целом это соответствует действительности - но с оговорками.

Роли на базе dnf и yum. Здесь проблем не было. Модуль ansible.builtin.dnf работает корректно, обработка репозиториев через dnf.conf совместима. Ролям, которые управляют пакетами стандартными средствами, адаптация не понадобилась.

Роли с systemctl и unit-файлами. Тоже прошло без правок. Systemd в RED OS 9.0 актуальной версии, поведение при enable/start предсказуемо. Это важно, потому что у нас несколько ролей управляют сложными зависимостями между сервисами - ни одна из них не потребовала вмешательства.

SELinux. А вот здесь мы споткнулись. У RED OS своя сборка политик SELinux, и она не совпадает один в один с той, что в RHEL 9. Несколько ролей, которые делают setsebool или работают с кастомными контекстами - упали. Не сразу, а на этапе, когда нужно было применить политику к конкретному каталогу или порту. Причина в том, что имена некоторых булевых переменных в политике РЭДОС отличаются от апстримного названия. Пришлось делать задачи с when: ansible_distribution == 'RED' и прописывать альтернативные имена булевых.

Роли для Podman и контейнеров. RED OS 9.0 включает Podman из коробки, и это, наверное, самое ощутимое улучшение по сравнению с 8.x. Роли, которые настраивают rootless Podman и systemd-юниты для контейнеров, прошли без изменений. Это заметно, потому что раньше Podman на RED OS 8 требовал ручной доустановки и часто конфликтовал с пакетной базой.

RPM-репозитории: зависимости и конфликты

Отдельная история - сторонние RPM-репозитории, которые мы используем для части продакшн-сервисов. Здесь картина неоднородная.

PostgreSQL. PGDG-репозиторий под RHEL 9 на RED OS 9.0 завёлся. Нужная версия PostgreSQL поставилась, библиотеки не конфликтуют. Клиентские утилиты, расширения - всё встало корректно. Это было важно, потому что именно PostgreSQL - центральное звено в нескольких продакшн-контурах.

ClickHouse. Официальный репозиторий Yandex настроен под el9, и с RED OS 9.0 он в целом совместим - с оговоркой: при установке ClickHouse Server возникает конфликт зависимостей на уровне одной из системных библиотек. Решается пакетом-заглушкой или явным пиннингом версии, но это ручная работа. Не катастрофа, но в автоматизированный деплой надо добавлять обход.

Nginx из официального репозитория nginx.org. Без нареканий.

Некоторые вендорские RPM для мониторинга. Тут всё зависит от конкретного вендора. Несколько агентов, которые мы используем, поставляются как RPM под el8 или el9. Часть встала корректно, часть потребовала проверки зависимостей руками - особенно те, которые тянут специфические версии openssl или libcurl.

Ядро и специфика КИИ

Одна из заявленных особенностей RED OS 9.0 - сборка ядра с учётом требований к КИИ: конкретные параметры компиляции, отключённые функции, которые не нужны на промышленных объектах и потенциально расширяют поверхность атаки. Проверить это в полной мере на стенде за несколько дней невозможно, но несколько вещей мы посмотрели.

Параметры ядра через sysctl применяются корректно, hardening-профили на базе scap-security-guide работают - для RHEL 9-профиля большинство правил применимы и к RED OS 9.0 с минимальными адаптациями. Встроенный аудит через auditd настраивается привычно.

То, что мы не успели проверить: поведение ядра под нагрузкой в конкретных сценариях промышленного контура и совместимость с некоторыми аппаратными платформами, которые у клиентов используются в КИИ. Это отдельная работа, которая требует реального оборудования, а не виртуального стенда.

Общее впечатление

RED OS 9.0 - это заметный шаг вперёд относительно 8.x. Podman, актуальное ядро, более аккуратная пакетная база. Если брать его как замену RHEL 9 с нуля - порог входа ниже, чем был. Если мигрировать с уже существующей инфраструктурой - совместимость высокая, но не стопроцентная: SELinux-политики и часть сторонних репозиториев потребуют внимания.

Для нас сейчас главный открытый вопрос - как вести смешанный парк, где часть хостов на RHEL 9, часть на RED OS 9.0, и при этом использовать одни Ansible-роли. Технически это решаемо через условия по ansible_distribution, но это означает дополнительный слой сопровождения. Пока мы его оцениваем как приемлемый, но не бесплатный.

Managed-сопровождение инфраструктуры в контексте КИИ всё больше упирается именно в этот вопрос: как удерживать автоматизацию в рабочем состоянии при смешанном парке ОС. Ответ пока в процессе.