В контейнере процесс видит только собственное дерево процессов, хотя процессы других контейнеров работают на том же узле. Какой механизм изоляции это обеспечивает?
Это обеспечивает PID namespace — пространство идентификаторов процессов в Linux. Оно создаёт для процесса отдельное представление дерева процессов: внутри контейнера он видит только процессы своего пространства и его дочерних пространств, хотя ядро хоста учитывает все процессы.
Обычные процессы Linux изначально находятся в общем пространстве PID и видят одну таблицу процессов. Для контейнеров этого недостаточно: изолированному приложению не следует видеть или случайно завершать процессы соседних приложений.
Пространства имён Linux появились как механизм разделения системных представлений между группами процессов. В сочетании с ограничениями ресурсов и изоляцией файловой системы они стали фундаментом контейнерной модели.
Если контейнеры используют общее пространство процессов, приложение внутри одного контейнера может получить сведения о процессах другого контейнера, отправлять им сигналы или ошибочно считать их частью собственной системы. Это усложняет безопасность, диагностику и управление жизненным циклом приложения.
Однако PID-изоляция не означает полной защиты от хоста. Процессы с достаточными привилегиями на узле могут видеть процессы контейнеров, а другие механизмы контейнерной конфигурации способны намеренно отключить изоляцию.
При создании PID namespace процесс получает собственный набор числовых идентификаторов PID. Один и тот же процесс может иметь разные PID: например, внутри контейнера он может быть процессом с PID 1, а в пространстве имён хоста — другим номером.
Процесс обычно видит процессы своего PID-пространства и вложенных пространств, но не процессы родительского или соседнего пространства. Поэтому контейнерное приложение воспринимает собственное дерево процессов как отдельную систему.
Первый процесс нового PID-пространства получает специальную роль PID 1. Он должен корректно обрабатывать сигналы завершения и подбирать осиротевшие процессы; если он завершается, ядро завершает процессы этого пространства. Поэтому запуск приложения через неподходящий процесс-обёртку может привести к проблемам с обработкой сигналов и завершением дочерних процессов.
PID namespace изолирует именно идентификаторы и видимость процессов, но не ограничивает их ресурсы. Для ограничения CPU и памяти применяются cgroups, для системных вызовов — seccomp, для прав доступа — capabilities и механизмы мандатного контроля, а для файлов и сети — другие пространства имён и политики.
Изоляция может быть ослаблена настройкой общего пространства процессов, например для тесно связанных контейнеров. Тогда контейнеры получают общий вид дерева процессов, что иногда удобно для отладки или специальных агентов, но уменьшает изоляцию.
В поде работают основной контейнер приложения и контейнер-агент. Агент должен наблюдать процессы приложения для диагностики, но при стандартной изоляции видит только собственное дерево и не может получить нужные сведения.
Вариант с отключением PID-изоляции решает задачу наблюдения, но расширяет область видимости агента и повышает последствия его компрометации. Вариант с отдельным механизмом мониторинга, который получает минимально необходимые права и работает через разрешённый интерфейс приложения, лучше сохраняет изоляцию, но требует дополнительной настройки.
Практичным решением будет включать общее пространство процессов только для доверенного диагностического сценария, ограничивать права агента и не считать сам факт видимости процессов достаточной авторизацией. Для обычных рабочих нагрузок предпочтительнее сохранять отдельные PID-пространства.
Нет, внутри контейнера он обычно видит PID, назначенный этому процессу в собственном пространстве имён. Тот же процесс одновременно имеет PID в пространстве хоста, но это отображение скрыто от обычного представления процессов внутри контейнера.
Нет. Он ограничивает видимость и адресацию процессов, но не заменяет контроль привилегий. Ошибочно выданные capabilities, доступ к интерфейсам ядра или уязвимость в привилегированном контейнере могут позволить воздействовать на хост или другие нагрузки.
PID 1 имеет особое значение для обработки сигналов и осиротевших дочерних процессов. Если приложение не умеет выполнять функции init-процесса, завершение контейнера может обрабатываться некорректно, а дочерние процессы — оставаться в неожиданном состоянии до завершения всего пространства имён.