Docker или Podman: rootless-режим меняет безопасность и расходы

Для нового Linux-сервера, где контейнеры должны работать без прав суперпользователя, разумно рассмотреть Podman. Ему не нужен постоянно работающий центральный демон, а службы можно связать с системным диспетчером. Если развёртывание уже зависит от Docker Compose и программ, обращающихся к интерфейсу Docker, практичнее сохранить Docker и настроить запуск без прав суперпользователя.

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

Безопасность определяется режимом запуска

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

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

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

Совместимость образа не равна совместимости развёртывания

Готовый образ обычно перенести проще, чем всю схему работы сервиса. Описание загрузки образов Podman показывает получение образов из реестров, включая Docker Hub, и чтение архивов в формате Docker. Совместимый образ можно запустить в обоих движках, но сам файл образа не задаёт поведение внешних инструментов, сетевых настроек и подключённых каталогов.

Особенно заметна разница там, где проект управляется через Compose. Документация команды Podman Compose поясняет, что команда передаёт выполнение внешнему поставщику Compose и обеспечивает его связь с локальным сокетом. Похожее имя команды не гарантирует одинакового результата для проекта с несколькими службами. При переносе приходится учитывать используемые возможности сборки, сеть, тома и программы, которые ожидают определённого поведения интерфейса Docker.

Для отдельной серверной службы у Podman есть другой путь: определения Quadlet преобразуются в службы системного диспетчера. Так жизненный цикл контейнера можно связать с запуском системы, зависимостями служб и журналами. Если существующий проект уже развёртывается проверенным набором файлов Compose, перенос этих описаний потребует работы и повторной проверки. Экономия памяти на постоянно работающем демоне может оказаться менее важной, чем стоимость такой миграции.

Что измерили: память, запуск и сеть

В замерах Botmonster на одной машине Docker работал с правами суперпользователя, а Podman — без них; за 20 запусков короткого контейнера с заранее загруженным образом среднее время составило соответственно 352 и 342 мс, а сразу после перезапуска без контейнеров управляющие процессы Docker занимали вместе 144 МБ памяти. Близкое время запуска в этих условиях не показывает преимущества какого-либо движка при одинаковых настройках привилегий. Значение памяти относится к конкретной машине и состоянию демона, а не к обязательному расходу каждой установки.

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

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

Выбор для сервера, рабочей станции и системной службы

• Одиночный сервер с новыми сервисами. Podman подходит, если контейнеры планируется запускать от отдельной обычной учётной записи, а жизненным циклом служб управлять средствами системы. Отсутствие постоянного демона сокращает расход памяти в простое. При этом права на каталоги данных и способ публикации портов всё равно нужно задать для конкретного сервиса.
• Рабочая станция разработчика. Сохранить Docker разумно, если сборка, тесты и локальный запуск уже опираются на Docker Compose либо на его программный интерфейс. Запуск без прав суперпользователя позволяет уменьшить привилегии, не заменяя привычный движок. Проверка совместимости при таком выборе касается прежде всего текущих инструментов и файлов развёртывания.
• Системная служба на Linux. Podman с Quadlet удобен, когда контейнер должен подчиняться обычным правилам запуска, перезапуска и ведения журналов службы. Для действующего проекта на Compose предпочтение может измениться: перенос описаний и проверка зависимых инструментов тоже требуют времени. Этот расход нужно сопоставлять с памятью, которую занимает демон на данном сервере.

Как получить сравнимые расходы на своём сервере

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

Читайте также:

• 93,4% популярных образов Docker Hub содержат критическую уязвимость
• «Безопасной от ИИ» профессии нет: прогнозы расходятся сильнее рейтингов
• ER в Instagram нельзя сравнивать вслепую: знаменатель меняет результат