Container runtime security

Контейнер — это процесс, а не VM

Самый важный факт о безопасности контейнеров: контейнер — это не маленькая виртуальная машина. Это обычный Linux-процесс на хосте, обёрнутый в namespace’ы (которые меняют то, что он видит — своё дерево PID, монтирования, сеть) и cgroup’ы (которые ограничивают то, что он использует — CPU, память). Чего у него принципиально нет, так это собственного ядра. Каждый контейнер на узле вызывает то же самое ядро хоста, что и всё остальное. У VM между нагрузкой и железом стоят гипервизор и гостевое ядро; у контейнера — одно общее ядро и немного учётной механики.

Это полностью меняет модель угроз. В VM выйти на хост означает победить гипервизор — твёрдую, хорошо изученную границу. В контейнере «побег» означает заставить общее ядро сделать что-то от твоего имени, что пересекает забор namespace’а: баг ядра, чрезмерно широкую капабилити, доступный на запись путь хоста, syscall, который никогда не фильтровался. Container escape (побег из контейнера) — это событие, когда код внутри контейнера получает исполнение кода или доступ к файлам на хосте. Это не экзотика: CVE-2019-5736 в runc позволял вредоносному образу перезаписать бинарь runc на хосте и выполниться от root на хосте; CVE-2022-0492 злоупотребляла путём release-agent в cgroups v1, чтобы сбежать из контейнера вообще без экзотических привилегий. Граница реальна, но тонка, и твоя задача в рантайме — сделать её толще дефолта.

Capabilities: перестань быть root в 40 степенях

В классическом UNIX всё бинарно: ты либо root (uid 0, может всё), либо нет. Linux capabilities дробят всемогущество root на ~40 отдельных привилегий, которые можно выдавать или сбрасывать по одной: CAP_NET_BIND_SERVICE (привязка к портам ниже 1024), CAP_NET_RAW (raw-пакеты, ping), CAP_SYS_ADMIN (свалка настолько широкая, что её зовут «новым root»), CAP_SYS_PTRACE, CAP_DAC_OVERRIDE (обход проверки прав на файлы) и так далее.

Вот ловушка: контейнер, работающий от root, — это не то же самое, что контейнер от всемогущего root хоста, но по умолчанию он всё равно получает щедрый дефолтный набор капабилити. Рефлекс зрелого инженера — сбросить ALL, потом добавить обратно только то, что нагрузке доказуемо нужно, — почти всегда ничего, потому что типичный веб-сервис привязывается к высокому порту и читает свои же файлы. Капабилити, которые делают побег возможным — CAP_SYS_ADMIN (mount, BPF, множество путей побега), CAP_SYS_MODULE (загрузка модуля ядра = мгновенный конец игры), CAP_DAC_READ_SEARCH (чтение файлов CVE-2014-9357 / Docker «Shocker»), CAP_NET_ADMIN — это ровно те, которые нормальное приложение никогда не использует. Сбросить их ничего не стоит, а целые классы побега исчезают. Антипаттерн обратный: --privileged, который не просто выдаёт все капабилити — он ещё и отключает seccomp/AppArmor и открывает устройства хоста, из-за чего и фигурирует почти в каждом реальном разборе побега из контейнера.

Seccomp: сократи поверхность атаки через syscall’ы

Капабилити гейтят привилегированные операции; seccomp (secure computing mode) гейтит сами syscall’ы. Ядро Linux экспонирует ~300–400 системных вызовов, и эта поверхность и есть поверхность атаки — любой эксплойт ядра в контейнере в конечном счёте это «вызови такой syscall с такими аргументами». seccomp-профиль — это allowlist (или denylist) syscall’ов, применённый к процессу; заблокированный syscall возвращает EPERM или убивает процесс вместо входа в путь ядра.

Практические числа важны. Дефолтный seccomp-профиль Docker уже блокирует ~44 самых опасных syscall’а — mount, ptrace чужих процессов, kexec_load (загрузить новое ядро), bpf, keyctl, namespace-трюки unshare/setns, — и один этот дефолт нейтрализовал несколько реальных CVE-побегов, зависевших от теперь заблокированного syscall’а. Зрелый сбой, который надо распознать: в Kubernetes seccomp не включён по умолчанию для старых кластеров. Под без заданного seccompProfile исторически работал unconfined — вся поверхность syscall’ов открыта, — поэтому современный рефлекс это задать seccompProfile: { type: RuntimeDefault } на весь кластер (а новые версии Kubernetes ставят это по умолчанию). Цена реальна, но мала: слишком тугой кастомный профиль может сломать нагрузку, которой легитимно нужен необычный syscall (некоторые JIT, приложения с активным io_uring), поэтому ход такой — RuntimeDefault как базовая линия, а кастомный профиль только когда ты измерил, какие syscall’ы приложение реально делает.

Read-only корневая ФС и остальной набор харденинга

Третий столп — read-only корневая файловая система (readOnlyRootFilesystem: true). Если файловая система контейнера неизменяема, атакующий, получивший исполнение кода, не может подбросить веб-шелл, перезаписать бинарь на $PATH, изменить конфиг ради закрепления или подготовить инструменты для следующего шага. Большинство приложений вообще не пишут в свой образ — они пишут в базу, в лог-сток или во временную папку, — поэтому ты монтируешь маленький emptyDir на /tmp для по-настоящему эфемерных записей и замораживаешь всё остальное. Это превращает «у меня есть шелл» в «у меня есть шелл, который ничего не может сохранить», что ломает закрепление и большую часть подготовки инструментов.

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

Когда флагов харденинга мало: более сильная изоляция

Иногда нагрузка по-настоящему недоверенная — ты запускаешь чужой код (CI-задачи, мультитенантную платформу функций, сгенерированный ИИ код в песочнице). Флаги харденинга сокращают поверхность атаки общего ядра, но не устраняют её; ядро всё ещё общее, поэтому достаточно хороший 0-day в ядре всё равно сбегает. Для этого уровня ответ — более сильный рантайм изоляции: gVisor (ядро в user-space, перехватывающее syscall’ы, так что контейнер никогда не касается реального ядра напрямую) или Kata Containers / Firecracker microVM (реальное лёгкое гостевое ядро на каждую нагрузку, изоляция уровня гипервизора со стартом почти как у контейнера). Они стоят некоторой производительности и операционной сложности, поэтому ты не тянешься к ним ради своих first-party сервисов — но для по-настоящему враждебного кода «закалять общее ядро» — неверная высота, а «не делить ядро» — верная.