[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-bezopasnost-konteynerov-kak-rabotaet-izolyatsiya-konteynerov-na-urovne-yadra-linux":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":21,"progress":22,"seo":23},324,"kak-rabotaet-izolyatsiya-konteynerov-na-urovne-yadra-linux",9,"bezopasnost-konteynerov","Безопасность контейнеров","🛡️","Как работает изоляция контейнеров на уровне ядра Linux?","\u003C!-- grade: -->\n\nКонтейнеры — это **не виртуальные машины**. Они не содержат собственного ядра операционной системы. Все контейнеры на хосте разделяют одно ядро Linux, а изоляция обеспечивается тремя основными механизмами ядра: **namespaces** (изоляция видимости), **cgroups** (ограничение ресурсов) и **union filesystems** (послойная файловая система). Понимание этих механизмов необходимо для оценки реальной степени изоляции и осознанного выбора дополнительных мер защиты.\n\n**1. Linux Namespaces (изоляция видимости ресурсов):**\n\nNamespaces создают для процесса внутри контейнера иллюзию собственной изолированной операционной системы. Каждый namespace изолирует определённый тип системных ресурсов:\n\n| Namespace | Что изолирует | Флаг clone() | Описание |\n|-----------|--------------|--------------|----------|\n| **PID** | Процессы | CLONE_NEWPID | Контейнер видит только свои процессы. Процесс entrypoint получает PID 1 внутри контейнера, хотя на хосте у него другой PID |\n| **NET** | Сеть | CLONE_NEWNET | Собственный сетевой стек: IP-адрес, интерфейсы, таблица маршрутизации, порты |\n| **MNT** | Файловая система | CLONE_NEWNS | Собственные точки монтирования, изолированные от хоста |\n| **UTS** | Hostname | CLONE_NEWUTS | Собственное имя хоста (hostname), независимое от реального хоста |\n| **IPC** | Межпроцессное взаимодействие | CLONE_NEWIPC | Собственные семафоры, очереди сообщений, разделяемая память |\n| **USER** | Пользователи | CLONE_NEWUSER | Собственная таблица UID\u002FGID. Root (UID 0) внутри контейнера может маппиться на непривилегированного пользователя на хосте |\n| **Cgroup** | Cgroup-иерархия | CLONE_NEWCGROUP | Контейнер видит собственную иерархию cgroups, а не всю иерархию хоста |\n\n```bash\n# Посмотреть namespaces контейнера по PID процесса\ndocker inspect --format '{{.State.Pid}}' my-container\n# Например, PID = 12345\n\nls -la \u002Fproc\u002F12345\u002Fns\u002F\n# lrwxrwxrwx 1 root root 0 ... cgroup -> cgroup:[4026532234]\n# lrwxrwxrwx 1 root root 0 ... ipc -> ipc:[4026532232]\n# lrwxrwxrwx 1 root root 0 ... mnt -> mnt:[4026532230]\n# lrwxrwxrwx 1 root root 0 ... net -> net:[4026532235]\n# lrwxrwxrwx 1 root root 0 ... pid -> pid:[4026532233]\n# lrwxrwxrwx 1 root root 0 ... user -> user:[4026531837]\n# lrwxrwxrwx 1 root root 0 ... uts -> uts:[4026532231]\n```\n\nКаждый namespace идентифицируется числовым inode (числа в квадратных скобках). Контейнеры с одинаковыми inode делят один namespace. Например, если USER namespace совпадает с хостовым — значит, user namespace remapping не включён.\n\n**2. Cgroups (Control Groups — ограничение ресурсов):**\n\nЕсли namespaces отвечают за то, что контейнер **видит**, то cgroups отвечают за то, сколько ресурсов он может **потребить**:\n\n| Подсистема | Что ограничивает |\n|------------|-----------------|\n| **cpu** | Процессорное время (CPU shares, quotas) |\n| **memory** | Оперативная память (limits, swap) |\n| **blkio** | Disk I\u002FO (пропускная способность, IOPS) |\n| **pids** | Количество процессов (защита от fork bomb) |\n| **cpuset** | Привязка к конкретным ядрам CPU (CPU pinning) |\n| **devices** | Доступ к устройствам хоста (\u002Fdev\u002F*) |\n\n```bash\n# Просмотр cgroup-лимитов контейнера\ncat \u002Fsys\u002Ffs\u002Fcgroup\u002Fmemory\u002Fdocker\u002F\u003Ccontainer_id>\u002Fmemory.limit_in_bytes\ncat \u002Fsys\u002Ffs\u002Fcgroup\u002Fcpu\u002Fdocker\u002F\u003Ccontainer_id>\u002Fcpu.cfs_quota_us\ncat \u002Fsys\u002Ffs\u002Fcgroup\u002Fpids\u002Fdocker\u002F\u003Ccontainer_id>\u002Fpids.max\n```\n\nДля Java особенно важно: начиная с Java 10, JVM по умолчанию включает `-XX:+UseContainerSupport` и корректно читает cgroup-лимиты для автоматической настройки размера heap и количества потоков GC. Без этой поддержки JVM может попытаться использовать всю RAM хоста, что приведёт к OOMKill.\n\n**3. Seccomp (Secure Computing — фильтрация системных вызовов):**\n\nSeccomp позволяет фильтровать системные вызовы (syscalls), доступные процессу. Docker по умолчанию применяет профиль, блокирующий примерно 44 системных вызова из более чем 300, включая: `reboot` (перезагрузка хоста), `mount` (монтирование файловых систем), `swapon` (управление swap), `clock_settime` (изменение системного времени), `bpf` (загрузка BPF-программ) и другие потенциально опасные вызовы.\n\n**4. Linux Capabilities:**\n\nТрадиционная модель привилегий Linux бинарна: процесс либо root (всемогущий), либо обычный пользователь. Capabilities дробят привилегии root на примерно 40 отдельных единиц, позволяя дать процессу только необходимые:\n\n```bash\n# Capabilities контейнера по умолчанию\ndocker run --rm alpine cat \u002Fproc\u002F1\u002Fstatus | grep Cap\n# CapPrm: 00000000a80425fb\n# Включает: CHOWN, DAC_OVERRIDE, FSETID, FOWNER, NET_RAW и др.\n```\n\nDocker по умолчанию оставляет минимальный набор capabilities, но для максимальной безопасности рекомендуется `--cap-drop=ALL` с добавлением только действительно нужных.\n\n**5. Ограничения изоляции контейнеров:**\n\nПоскольку контейнеры разделяют ядро Linux с хостом, существуют принципиальные ограничения изоляции:\n\n- **Уязвимость ядра = потенциальный побег из контейнера** (container escape). Эксплоит уязвимости ядра может дать злоумышленнику доступ к хостовой системе.\n- **`\u002Fproc` и `\u002Fsys` частично доступны** — некоторые файлы в этих виртуальных файловых системах содержат информацию о хосте.\n- **Флаг `--privileged` полностью отключает изоляцию** — контейнер получает доступ ко всем устройствам хоста и capabilities root.\n- **Время (clock) является общим** для всех контейнеров и хоста — нет способа изолировать системные часы.\n\n**6. Усиление изоляции (для высокочувствительных систем):**\n\nКогда стандартной контейнерной изоляции недостаточно, существуют технологии, добавляющие дополнительный уровень:\n\n| Технология | Описание | Накладные расходы |\n|-----------|----------|-------------------|\n| **gVisor** (Google) | Виртуальное ядро в user-space, перехватывающее все syscalls контейнера | Средние (замедление syscall-heavy нагрузок) |\n| **Kata Containers** | Лёгкие виртуальные машины с собственным ядром, OCI-совместимые | Низкие (быстрый старт, но больше RAM) |\n| **Firecracker** (AWS) | microVM с минимальным VMM, используется в AWS Lambda и Fargate | Минимальные (старт за ~125 мс) |\n\n```yaml\n# Использование gVisor как runtime class в Kubernetes\napiVersion: v1\nkind: Pod\nspec:\n  runtimeClassName: gvisor  # Указать runtime class\n  containers:\n  - name: banking-app\n    image: registry.bank.local\u002Fbanking-service:1.0.0\n```\n\ngVisor перехватывает все системные вызовы контейнера и выполняет их в собственном ядре (Sentry), работающем в user-space. Даже при наличии уязвимости в «ядре» gVisor атакующий не получит доступ к реальному ядру хоста. Для банковских систем с обработкой платёжных данных стоит рассмотреть Kata Containers или gVisor как дополнительный уровень изоляции.","","senior",[15,16,17,18,19,20],"cgroups","capabilities","linux","seccomp","container-security","namespaces",[],null,{"title":24,"description":25,"ogTitle":24,"ogDescription":26,"keywords":27,"schemaAnswer":34,"featuredSnippetReady":35},"Изоляция контейнеров: namespaces, cgroups, seccomp — Gymterview","Как работает изоляция контейнеров на уровне ядра Linux? Linux namespaces (PID, NET, MNT, UTS, IPC, USER), cgroups, seccomp, capabilities. gVisor, Kata Containers для усиления изоляции.","Механизмы изоляции контейнеров на уровне ядра Linux: namespaces, cgroups, seccomp, capabilities. Ограничения изоляции и технологии усиления — gVisor, Kata Containers.",[28,29,15,18,30,31,32,33],"изоляция контейнеров","Linux namespaces","capabilities Linux","gVisor","Kata Containers","container escape","Контейнеры используют одно ядро Linux с хостом, а изоляция обеспечивается механизмами ядра. Linux Namespaces (PID, NET, MNT, UTS, IPC, USER, Cgroup) создают иллюзию отдельной ОС. Cgroups ограничивают потребление ресурсов (CPU, memory, blkio, pids). Seccomp фильтрует системные вызовы — Docker блокирует ~44 опасных из 300+. Capabilities дробят привилегии root на отдельные права. Ограничения: общее ядро означает, что уязвимость ядра может привести к container escape. Для усиления изоляции применяют gVisor (виртуальное ядро), Kata Containers (лёгкие VM) и Firecracker (microVM).",true]