Настройка Podman как rootless-альтернативы Docker

Rootless-контейнеры на Podman: что ломается в привычной схеме

Классическая схема запуска контейнеров предполагает, что управляющий демон работает от суперпользователя, а процесс внутри получает корневые права по умолчанию. Пока всё стабильно, это незаметно: служба живёт в своей изоляции, тома монтируются, порты публикуются. Но стоит найтись уязвимости или ошибке в правах доступа — и атакующий оказывается не в песочнице, а на самом узле, с видом на соседние контейнеры, сокет управления и файловую систему хоста.

Цена такой архитектуры — единая точка отказа. Один скомпрометированный контейнер равносилен компрометации всей машины: с него снимаются секреты соседних служб, читаются общие тома, правятся конфигурации. Изоляция служб перестаёт быть границей безопасности и остаётся только удобной упаковкой.

Podman убирает из уравнения привилегированный демон: в rootless-режиме контейнеры запускаются в отдельном пространстве имён пользователя, где root внутри соответствует непривилегированному идентификатору снаружи. Даже при удачном прорыве приложение получает права обычного пользователя — без записи в системные каталоги и без доступа к чужой контейнерной инфраструктуре.

Переход меняет привычки: иначе настраиваются тома и порты ниже 1024, часть образов требует явного сопоставления идентификаторов, а управление без системного демона опирается на другие механизмы. Разбираем, как это закрывается и что именно нужно перестроить в существующем контуре.

Что даёт перевод служб на контейнеры без прав root

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

Дальше — изоляция сбоя. Ошибка в одном сервисе больше не означает падение всего узла: у каждого контейнера свои лимиты по памяти и процессору, и исчерпание ресурсов одним процессом не забирает с собой остальные. Класс отказов «упал узел — легли все службы» уходит из практики, а вместе с ним и самая дорогая часть простоя сервиса — время на подъём всего хоста.

Автозапуск контейнеров описывается заранее: службы поднимаются после перезагрузки в заданном порядке, с политикой перезапуска и зависимостями между собой. Время восстановления службы измеряется десятками секунд вместо ручного разбора «что и в каком порядке запускать» — инженер не занят рутиной, а только проверяет результат.

И единая среда разработки и продуктива: локально и на сервере используется один образ и одна команда запуска, отличаются только параметры окружения и точки монтирования. Это убирает расхождения «у меня работает, на сервере нет», а Podman на рабочей машине ведёт себя так же, как на боевом узле, поэтому предварительная проверка перестаёт быть отдельным этапом.

Podman и альтернативы: сравнение режимов запуска

Режим запуска определяет, что произойдёт при компрометации контейнера и насколько предсказуемо сервис переживёт перезагрузку узла. Привилегированный движок удобен: контейнер видит устройства хоста, занимает порт ниже 1024 и монтирует любой каталог. Плата — общий демон и процесс с правами root, где ошибка в образе превращается в полный доступ к узлу.

Контейнер от имени сервисного пользователя снимает это ограничение: ядро держит процесс в рамках прав этого пользователя, и выход за них требует отдельной ошибки конфигурации. Совместимость с привычными командами сохраняется — Podman повторяет синтаксис запуска, поэтому скрипты развёртывания переносятся заменой вызова, а не переписыванием. Ограничения режима видны на практике: привилегированные порты требуют проброса, слои пишутся в пространстве пользователя, нужен выделенный диапазон subuid/subgid.

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

Порядок перевода служб: от аудита узла до передачи

Переводим службы на rootless-контейнеры (Podman) этапами: каждый следующий опирается на результат предыдущего. Ошибка видна на шаге, где она появилась, а не в момент отказа продуктивной службы.

1. Аудит узла. Собираем инвентаризацию: какие службы запущены, от чьего имени, какие порты и каталоги занимают, что стартует из systemd и планировщика. Фиксируем зависимости между сервисами — без них схема размещения выйдет произвольной.
2. Схема размещения служб. Раскладываем сервисы по пользователям: что уходит в rootless-контур, что остаётся системным, где нужны общие тома и проброс портов. Схему согласуем с вами до правок на узле.
3. Подготовка окружения. Включаем пользовательские пространства имён, задаём ограничения ресурсов и правила для длительных сессий. Проверяем, что контейнеры живут после выхода администратора из системы — иначе падают вместе с сессией.
4. Настройка изоляции и автозапуска. Каждой службе — свой пользователь, свои тома и порты, права на файлы только там, где нужно. Автозапуск оформляем описаниями служб с явным порядком старта, повторяющим реальные связи сервисов.
5. Проверка отказоустойчивости. Перезагружаем узел, обрываем сеть, гасим службы по одной, заполняем диск. Видим, что поднимается само, что теряет данные, а что требует ручного вмешательства.
6. Передача в эксплуатацию. Отдаём конфигурацию, схему размещения, инструкции по типовым операциям и откату. Прогоняем сопровождение по сценариям, чтобы работа узла не зависела от автора внедрения.

Пакет передачи: конфигурации, схемы, регламенты доступа

Передача устроена так, что команда заказчика остаётся с рабочим контуром, а не с устными договорённостями. Rootless-режим Podman добавляет к этому свои нюансы: права пользователя, маппинг идентификаторов, отдельные пространства имён — всё, что легко сломать при следующем изменении, если не зафиксировано документально. Поэтому отдаём комплект артефактов в репозитории, который проходит ревью как код и обновляется вместе с сервисом.

• Файлы конфигурации. Юниты для запуска контейнеров как пользовательских служб, настройки реестров и хранилища образов, лимиты ресурсов, параметры ротации журналов — с комментариями, что и зачем меняется при росте нагрузки.
• Схемы развёртывания. Размещение служб по узлам и пользовательским учётным записям, какие тома и сетевые пространства общие, где проходит граница между средами разработки и эксплуатации.
• Политики доступа. Кто из сотрудников и какие группы управляют службами, откуда разрешена сборка образов, правила проверки подписи, запрет привилегированных контейнеров и монтирования системных каталогов.
• Регламент обновления. Порядок выката новой сборки, проверки перед переключением трафика, поведение при занятых томах, точки согласования и критерии, по которым релиз считается успешным.
• Документация и откат. Пошаговые инструкции на типовые операции, схема зависимостей сервисов, порядок возврата к предыдущей сборке с проверкой, что служба поднялась и отвечает на запросы.
• Диагностика и передача знаний. Набор команд для разбора инцидентов, разбор конфигураций на живой среде и ответы на вопросы инженеров заказчика — чтобы сопровождение не зависело от нас.

Кейс: перевод служб на контейнеры без привилегий

Службы на 42 узлах запускались от суперпользователя и делили доступ к сокету контейнерного движка. Любой скомпрометированный компонент получал права на хост, а падение одной службы нередко лечилось перезапуском всей машины.

Восстановление после такого сбоя занимало 35–40 минут, обновления выносили в ночное окно на 3 часа, часть выкатов откатывали вручную. Класс отказов «перезапуск всей машины» срабатывал в среднем 9 раз за квартал.

Что изменили

Службы перевели в rootless-режим Podman: каждая работает под отдельным системным пользователем без доступа к привилегированному движку. Автозапуск — пользовательские юниты systemd с lingering, поэтому служба поднимается после перезагрузки узла без ручного входа.

Тома подключили как bind-mount с метками SELinux, публикацию портов ограничили списком нужных, образы — из внутреннего реестра с проверкой подписи. Политику лимитов и журналирование прописали на уровне службы, а не узла.

Что стало

«Раньше одна упавшая служба тянула за собой весь узел, теперь перезапускается только её дерево процессов», — инженер сопровождения. Второй участник короче: «Окно обновления перестало быть ночным — выкатываем днём и не будим дежурного».

Четыре узла оставили с привилегиями: службам там нужен прямой доступ к оборудованию, это зафиксировано отдельной политикой. Остальное закрыто — компрометация процесса больше не даёт прав на хост, а время восстановления сократилось почти на порядок.

Что делать, если Podman уже развёрнут частично

Пока Podman закрывает часть служб, а остальные работают по прежней схеме, это рабочее состояние, а не аварийное. Опасность не в сосуществовании двух моделей запуска, а в двойной поддержке: два набора правил доступа, два способа смотреть журналы, два способа обновлять образы. Задача — не откатывать сделанное, а задать порядок, в котором переезжает остаток.

Первый шаг — инвентаризация: что уже в rootless-режиме, что осталось, и от чего каждая служба зависит — тома, порты, учётные записи, имена соседей по сети. Большая часть историй «сломалось после переезда» объясняется именно связями: соседняя служба не разрешается по имени в новой схеме или каталог становится недоступен по правам. Это фиксируется до любых перемещений.

Дальше — очередь приоритетов. Первыми переезжают службы без собственного состояния: внешний прокси, кэш, обработчики очередей — они поднимаются за секунды, и ошибка стоит минуты. Службы с данными идут последними: им нужны плановое окно, согласованная копия и проверка целостности после.

Пока обе схемы живы, вход и сеть выносят на уровень, не зависящий от способа запуска. Имена и точки входа остаются прежними, и службы не знают, где живёт сосед — переход растягивается без остановки работы.

Завершён он не тогда, когда всё запущено в rootless-режиме, а когда на каждую службу остался один способ запуска, один способ доставки журналов и один способ обновления. Двойная поддержка заканчивается вместе с последним дублирующим набором правил.

Изоляция, автозапуск и совместимость: технические сомнения

Все возражения по Podman сводятся к четырём-пяти сценариям: как отдавать трафик на низкие порты, что с правами на данные, запустятся ли готовые образы, переживут ли контейнеры перезагрузку узла и можно ли переводить сервисы по одному. Разбираем каждый по существу — с указанием, где нужна настройка, а где ограничение действительно есть.

Как решается доступ к файловой системе и сетевым ресурсам?

Каталоги данных монтируются с явным владельцем — пользователем, от которого работает контейнер, иначе процесс внутри не сможет писать. На узлах с SELinux тома помечаются метками контекста при монтировании, иначе доступ блокируется на уровне мандатного контроля. Внутренние сети создаются как пользовательские, сервисы видят друг друга по именам, а наружу публикуются только нужные порты.

Совместимы ли существующие образы?

Podman работает с OCI-образами, поэтому собранные ранее образы запускаются без пересборки — меняется команда запуска и способ описания сервисов. Основные правки касаются описаний: путей монтирования, названий сетей, healthcheck и порядка старта зависимостей. Эти расхождения выявляются на этапе переноса в тестовом окружении, а не на боевом узле.

Поднимутся ли контейнеры после перезагрузки узла?

Сами по себе — нет: rootless-процессы не поднимает системный менеджер инициализации. Решается пользовательскими юнитами и включённым lingering, тогда сервисы стартуют при загрузке, перезапускаются после падения и корректно останавливаются в заданном порядке. Это же даёт понятную картину зависимостей и логов.

Можно ли перевести часть сервисов, а часть оставить как есть?

Да, и это самый безопасный путь. Узлы с разными средами сосуществуют, пока не конфликтуют за порты и тома; внешний прокси маршрутизирует трафик по сервисам. Перевод идёт группами, с откатом каждой группы отдельно — сбой на одном сервисе не затрагивает остальные.

Обсудим задачу: какие данные нужны для оценки

Предметная оценка собирается из фактов об инфраструктуре, а не из общих пожеланий. Чем точнее вы опишете текущее состояние и ограничения, тем меньше допущений в плане работ и тем реалистичнее сроки. Ниже — минимум, которого нам обычно хватает, чтобы вернуться с оценкой и планом.

• Перечень узлов и служб. Сколько хостов и какие у них роли, что уже в контейнерах, а что останется на хосте: системные демоны, планировщик задач, локальные базы, файловые сервисы.
• Текущий способ запуска. Compose-файлы, systemd-юниты, скрипты развёртывания, свой реестр образов — по ним видно, что переносится как есть, а что требует переупаковки.
• Требования к изоляции. Нужны ли раздельные пользователи и сетевые сегменты между службами, доступ к привилегированным портам, общие тома — от этого зависит схема запуска без root в Podman и порядок раздачи прав.
• Окна обновления. Когда допустимо перезапускать службы, какой простой считаете приемлемым, есть ли жёсткие периоды недоступности и в каком порядке можно выкатывать узлы.
• Доступ к данным. Где лежат тома и конфиги: локальные диски или сетевое хранилище, что монтируется, как устроены резервные копии, есть ли данные, которые нельзя выносить за пределы узла.
• Целевые показатели. Что считаем результатом: время подъёма узла с нуля, время восстановления после сбоя, доля служб без root, доля автоматизированных проверок.

Опишите задачу в свободной форме — этого достаточно, чтобы вернуться с оценкой и планом работ.