Podman: почему безопасность контейнеров требует пересмотра привычных практик

Podman — не просто «безопасный Docker». Это другой способ работать с контейнерами

Введение: почему Podman не про «улучшенный Docker»

Podman не позиционирует себя как полноценная замена Docker. Скорее, это инструмент, который заставляет пересмотреть привычные практики иначе, чем просто «тот же Docker, но с флагом --security-opt». Его архитектура без центрального демона и rootless-режим по умолчанию не просто добавляют безопасности — они меняют саму парадигму: контейнеры здесь не управляемые ресурсы, а изолированные процессы, которые должны быть безопасны так же строго, как и друг от друга. Это не маркетинг. Это фундаментальный сдвиг в том, как DevOps-команды строят пайплайны, запускают сервисы и диагностируют ошибки.

Но у такого сдвига есть цена. То, что работало в Docker «из коробки», в Podman требует явной настройки SELinux, маппинга UID/GID и понимания, почему том, который монтировался без проблем в Docker, внезапно становится недоступным. Разработчик, привыкший монтировать тома без размышлений о контекстах, сталкивается с ошибками Permission denied, даже если на хосте у него полные права. Это не баг. Это следствие философии Podman: безопасность по умолчанию, а не удобство по умолчанию.

Первая ловушка: почему контейнер не запускается — и в чём виноват не Docker

Типичная ситуация: скопировал команду из Docker в Podman — и получил ошибку, хотя ни образ, ни Dockerfile не менялись. Причина не в контейнере, не в образе и не в Dockerfile. Причина в том, как Podman обрабатывает тома в rootless-режиме.

В Docker rootless-режим — опция, которую можно включить или выключить. В Podman это базовая конфигурация. Но если разработчик привык монтировать тома так, как это работало в Docker, то в Podman его ждут два слоя ограничений: SELinux и маппинг UID/GID.

Что происходит на самом деле

Внутри контейнера том выглядит как owned by root, даже если на хосте это каталог пользователя. SELinux добавляет ещё один барьер: без явного контекста :Z или :z контейнер не может писать в том. То, что казалось очевидным в Docker, в Podman требует явной настройки. Это не дефект — это следствие модели безопасности, где у контейнера нет неявных привилегий на хосте.

Рассмотрим простой пример:

mkdir ~/app_data
podman run -v ~/app_data:/app/data alpine touch /app/data/file.txt

Эта команда завершится с ошибкой Permission denied, даже если пользователь имеет полные права на каталог ~/app_data. Причина — в том, как Podman обрабатывает тома в rootless-режиме.

Корень проблемы: три слоя защиты

1. UID/GID внутри контейнера vs. на хосте
   Внутри контейнера том owned by root, а на хосте — текущим пользователем. Если UID внутри контейнера не маппируется на хост, то права на файлах не совпадают. В Docker rootless-режим тоже использует маппинг UID/GID, но его настройка менее прозрачна и чаще игнорируется.

2. SELinux-контекст
   В Docker SELinux можно включить или выключить, но в Podman он интегрирован по умолчанию. Без явного контекста :Z или :z контейнер не может писать в том, так как SELinux блокирует доступ. В Docker SELinux тоже поддерживается, но требует ручной настройки.

3. Rootless-режим по умолчанию
   В Docker rootless-режим — опция, которую можно включить или выключить. В Podman это базовая конфигурация. Rootless-режим в Podman запускает каждый контейнер как отдельный процесс от имени текущего пользователя, а не через центральный демон. Это устраняет единую точку отказа и снижает поверхность атаки, но требует явной настройки прав.

Как это проявляется на практике

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

podman run -d --name app \
  -v /home/user/app_config:/etc/app \
  myapp:latest

Контейнер стартует, но приложение не может создать или изменить файлы в /etc/app. В логах ошибка:

Permission denied

Причина — в том, что внутри контейнера том owned by root, а на хосте — пользователем user. SELinux добавляет ещё один барьер: без явного контекста :Z или :z контейнер не может писать в том.

Rootless не равно «полная безопасность» — это другой уровень изоляции

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

Сеть: производительность и ограничения

Rootless-контейнеры используют slirp4netns для сетевого взаимодействия. Это снижает производительность по сравнению с rootful-режимом и блокирует привязку портов ниже 1024. В Docker rootless-режим тоже страдает от ограничений, но Podman не предлагает обходных путей «из коробки». Администратору нужно заранее планировать, какие порты использовать, или настраивать net.ipv4.ip_unprivileged_port_start.

Пример:

# Эта команда завершится с ошибкой, так как порт 80 требует root-привилегий
podman run -p 80:80 nginx:latest

Решение — использовать порты выше 1024 или настроить net.ipv4.ip_unprivileged_port_start:

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80

Но это не всегда возможно в ограниченных средах, таких как контейнеры или облачные инстансы.

Устройства: невозможность создания устройств внутри контейнера

В rootless-режиме Podman не может выполнять mknod внутри контейнера, даже в привилегированных контейнерах. Это ломает образы, которые требуют /dev/kmsg, /dev/console или других устройств.

Пример:

podman run --privileged alpine mknod /dev/kmsg c 1 11
# Ошибка: Operation not permitted

В Docker такие образы могли работать, если контейнер запускался с --privileged, но в Podman rootless даже привилегированные контейнеры не могут создавать устройства.

Вывод: rootless — это trade-off

Безопасность за счёт ограничений. Если в Docker можно было «запустить и забыть», то в Podman нужно думать о правах, контекстах и маппинге UID/GID задолго до деплоя.

Том, который не работает: как SELinux и UID/GID ломают привычные сценарии

Рассмотрим микро-сцену, которая повторяется в десятках командных строк.

Разработчик запускает контейнер с базой данных PostgreSQL, монтируя том для данных:

podman run -d --name postgres \
  -v /home/user/postgres_data:/var/lib/postgresql/data \
  -e POSTGRES_PASSWORD=secret postgres:latest

Контейнер стартует, но PostgreSQL не может создать файлы в /var/lib/postgresql/data. В логах ошибка:

initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Permission denied

На первый взгляд причина очевидна: владелец тома на хосте — пользователь user, а внутри контейнера том owned by root. Но это только половина проблемы. Вторая половина — SELinux.

SELinux: неявная блокировка доступа

Без явного контекста :Z или :z SELinux блокирует запись в том. Контейнер видит том как container_file_t, но без правильного контекста ядро отказывает в доступе.

Решение — добавить :Z:

podman run -d --name postgres \
  -v /home/user/postgres_data:/var/lib/postgresql/data:Z \
  -e POSTGRES_PASSWORD=secret postgres:latest

Теперь контейнер получает доступ. Но если другой контейнер попытается примонтировать тот же том, он получит ошибку, потому что :Z означает приватный доступ — только один контейнер может писать в том. Для разделяемого доступа нужно использовать :z, но тогда все контейнеры с этим контекстом получат доступ к тому.

UID/GID-маппинг: почему контейнер не может создать файл

UID/GID-маппинг добавляет ещё один слой сложности. Если внутри контейнера PostgreSQL запускается от UID 999, то на хосте этот UID маппируется на непривилегированный UID из /etc/subuid (например, 165536). Если маппинг не настроен, контейнер не может создавать файлы, даже если SELinux-контекст корректен.

Пример:

cat /etc/subuid
user:100000:65536

В этом случае UID 999 внутри контейнера маппируется на UID 100999 на хосте. Если этот UID не имеет прав на запись в /home/user/postgres_data, то PostgreSQL не сможет создать файлы.

Как это проявляется на практике

Разработчик пытается запустить контейнер с приложением, которое должно записывать логи в том:

podman run -d --name app \
  -v /home/user/app_logs:/var/log/app \
  myapp:latest

Приложение внутри контейнера запускается от UID 1000. На хосте этот UID маппируется на 101000. Если пользователь user не предоставил права на запись для UID 101000, то приложение не сможет записывать логи.

Решение — настроить маппинг UID/GID или использовать named volumes, которые Podman управляет автоматически.

Named volumes vs. bind-mount: что выбирать в реальных задачах

Для stateful-сервисов named volumes — оптимальный выбор. Podman создаёт том в ~/.local/share/containers/storage/volumes/ и назначает ему SELinux-контекст автоматически. Пример:

podman volume create db_data
podman run -v db_data:/var/lib/postgresql/data postgres:latest

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

Named volumes: плюсы и минусы

Плюсы:

• Podman управляет метаданными томов автоматически.
• SELinux-контекст назначается автоматически.
• Нет проблем с маппингом UID/GID, так как том полностью изолирован.
• Легче переносить между хостами.

Минусы:

• Том живёт в ~/.local/share/containers/storage/volumes/, что может быть неочевидно для администраторов.
• Размер тома ограничен квотами пользователя.

Bind-mount: плюсы и минусы

Плюсы:

• Простота доступа к файлам хоста.
• Удобно для отладки и разработки.
• Можно использовать системные каталоги, например, /etc/nginx.

Минусы:

• Требует явной настройки SELinux и маппинга UID/GID.
• Без :Z или :z контейнер не сможет писать в том.
• Проблемы с правами, если UID/GID не маппируются корректно.

Рекомендация

Для новых проектов по умолчанию используйте named volumes. Для legacy-систем или отладки — bind-mount с :Z/z. Не пытайтесь воспроизвести Docker-практики «один в один». Podman требует другого подхода.

Где Podman проигрывает Docker — и почему это не случайно

Podman не заменит Docker в сценариях, где критично использовать Docker Swarm или биндить порты ниже 1024 без дополнительной настройки. Rootless-режим Podman ограничивает сеть и производительность, а отсутствие центрального демона усложняет оркестрацию на больших кластерах.

Podman не заменит Docker в образах, которые требуют создания устройств внутри контейнера. Даже привилегированные контейнеры в rootless-режиме не могут выполнять mknod, что ломает образы, зависящие от /dev/kmsg или других устройств.

Podman не устраняет необходимость разбираться в SELinux и маппинге UID/GID. В Docker эти вопросы можно было отложить до момента, когда что-то сломается. В Podman они становятся частью ежедневной работы.

Когда использовать Podman

• В сценариях, где безопасность критична.
• В одноранговых средах, где нет центрального оркестратора.
• Для разработки и тестирования, где rootless-режим удобен.
• В средах, где Docker Swarm не используется.

Когда использовать Docker

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

Заключение: Podman — это не «безопасный Docker», а другой способ думать о контейнерах

Podman не называет себя заменой Docker, но позиционирует как инструмент, который заставляет пересмотреть привычные практики. Его архитектура rootless и бездемонная модель не просто добавляют безопасности — они меняют саму парадигму: контейнеры здесь не управляемые ресурсы демона, а изолированные процессы, которые должны быть безопасны так же строго, как и друг от друга. Это не маркетинг: это фундаментальный сдвиг в том, как DevOps-команды строят пайплайны, запускают сервисы и диагностируют ошибки.

Но сдвиг этот не бесплатный. То, что работало в Docker «из коробки», в Podman требует явной настройки SELinux, маппинга UID/GID и понимания, почему том, который отлично монтировался в Docker, внезапно становится недоступным. Это не баг — это следствие другой парадигмы. Podman не «безопасный Docker». Это инструмент, который заставляет думать о безопасности с самого начала, а не добавлять её потом.