Docker PID namespace: --pid=host и --pid=container

Что изолирует PID namespace в обычном контейнере

По умолчанию контейнер получает отдельный PID namespace: его процесс считает себя частью собственного дерева процессов и не видит обычный список процессов хоста. Это одна из базовых границ изоляции. Опция --pid меняет именно эту границу. При --pid=host контейнер разделяет PID namespace хоста, поэтому инструменты внутри него могут видеть host processes. При режиме container:<name-or-id> новый контейнер присоединяется к PID namespace уже существующего контейнера. Такой подход полезен для отладки slim/distroless образа: основной workload остаётся минимальным, а диагностический контейнер приносит свои инструменты. Но совместный namespace не означает автоматически совместную файловую систему, сеть или набор capabilities — это отдельные механизмы, и команды могут упереться в permissions даже при видимых PID.

Совет: Для диагностики приложения чаще безопаснее разделить PID namespace только с нужным контейнером, а не со всем host.

--pid=host против --pid=container:<id>

• обычный. процессы собственного контейнера. минимальный
• --pid=container:app. процессы PID namespace контейнера app. точечная диагностика workload
• --pid=host. процессы host PID namespace. широкая host-level диагностика

Как использовать отдельный debug-контейнер для процесса приложения

1. Найдите имя или ID целевого контейнера и сначала зафиксируйте его статус через docker ps/inspect, чтобы не присоединиться к устаревшему экземпляру после recreate.
2. Запустите диагностический image с --pid=container:<id>. Не добавляйте --privileged автоматически: начните с минимальных прав, необходимых конкретному инструменту.
3. Внутри debug-контейнера выполните ps и убедитесь, что видите процессы целевого workload. Если нужен доступ к его filesystem или network namespace, настраивайте эти механизмы отдельно — PID sharing сам их не даёт.
4. После диагностики удалите временный контейнер, например используя --rm. Не превращайте debug configuration в постоянную production-настройку без отдельной причины и threat review.
5. Если требуется host-level инструмент, только тогда рассматривайте --pid=host и ограничивайте окружение, пользователя и дополнительные capabilities настолько, насколько позволяет задача.

Предупреждение: --pid=host заметно ослабляет изоляцию. Не используйте его просто потому, что команда ps внутри контейнера показывает мало процессов.

Совместимость с userns и Docker Desktop

Docker документация по user namespace отмечает несовместимость userns-remap с sharing PID namespace хоста через --pid=host. Это важный сигнал: низкоуровневые namespace-режимы взаимодействуют с моделью безопасности, и флаг, работающий на одном daemon, может быть запрещён на другом. На Docker Desktop host для Linux-контейнера фактически означает namespace внутренней Linux VM, а не обязательно список процессов Windows/macOS. В hardened-конфигурациях Enhanced Container Isolation sharing host PID namespace может блокироваться полностью. Поэтому инструкции вида «добавьте --pid=host» нужно оценивать относительно среды, а не считать универсальным решением. Если цель — увидеть процесс приложения, точечный --pid=container обычно лучше формулирует намерение и меньше раскрывает соседние процессы.

Важно: Если --pid=host отвергается daemon, сначала проверьте user namespace/ECI и политику платформы, а не отключайте защиту вслепую.

Какие задачи PID sharing не решает

Общий PID namespace не публикует порты, не соединяет файловые системы и не даёт доступ к docker.sock. Он также не превращает обычный контейнер в privileged. Если strace или ptrace не работает, причина может быть в capabilities, seccomp или другой security policy. Если нужно прочитать конфигурацию приложения, потребуется отдельный mount или доступ к его namespace/filesystem. Если нужно проверить сетевые соединения именно из network namespace workload, нужен соответствующий network-namespace подход, а не только --pid. Полезная привычка — разделять диагностическую задачу на «какие процессы видеть», «какую сеть видеть», «какие файлы видеть» и «какие syscalls/capabilities нужны». Тогда вы добавляете только необходимые механизмы, а не выдаёте debug-контейнеру host PID, host network и privileged одновременно.

Пример диагностики distroless-контейнера без изменения production image

Представьте сервис в distroless image, где нет shell и ps, а нужно понять, какие дочерние процессы он запустил. Вместо пересборки production image с диагностическими утилитами можно запустить временный toolbox-контейнер с --pid=container:<app>. Его ps покажет процессы общего PID namespace, но сам toolbox останется отдельным контейнером со своей файловой системой. Если затем нужен stack trace или ptrace, добавляйте только конкретные права, которые требует инструмент, и учитывайте seccomp/capabilities. После завершения расследования контейнер удаляется через --rm, а production image остаётся неизменным. Такой паттерн полезен ещё и для аудита: изменение debug-инструментов не меняет digest приложения. Но он не магический — для чтения файлов процесса или его network sockets могут понадобиться другие namespace/mount настройки. Поэтому заранее определите диагностическую цель и не превращайте toolbox в privileged контейнер с host PID, host network и docker.sock одновременно без необходимости. Если задача сводится к списку процессов и родительским связям, этого обычно достаточно; дальнейшее расширение прав должно происходить только после конкретной ошибки доступа. Такой поэтапный подход сохраняет полезность namespace-sharing и одновременно уменьшает площадь атаки во время диагностики.

Как не спутать PID sharing с полным доступом к соседнему контейнеру

Общий PID namespace даёт видимость процессов, но не объединяет остальные namespaces автоматически. Debug-контейнер, запущенный с --pid=container:<id>, может видеть PID целевого контейнера, однако его файловая система, сеть, hostname и набор capabilities остаются отдельными, пока вы явно не изменили другие параметры. Поэтому сценарий “вижу процесс, но не вижу его файл” не означает, что PID sharing сломан. Для strace, gdb или чтения /proc могут понадобиться дополнительные capabilities и совместимые security-профили; добавляйте их только под конкретную диагностическую задачу. На daemon с userns-remap Docker документирует несовместимость sharing PID namespace с host, а в Docker Desktop Enhanced Container Isolation блокирует --pid=host как нарушение границы изоляции. Перед изменением настроек безопасности сначала проверьте, нужен ли вам host namespace вообще: для большинства расследований достаточно присоединиться к namespace одного контейнера и тем самым сузить область видимости.

Что учитывать

Условия меняются. Страница отражает состояние на 2026-09-22; при расхождении с официальной документацией приоритет у первоисточника.

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. docker container run). Пример и формулировки — редакция N1RO на 2026-09-22.

• docker container run
• Isolate containers with a user namespace
• Enhanced Container Isolation