Container image security

Образ — это унаследованные слои, а не твой код

Образ контейнера — это не твоё приложение. Это стопка read-only слоёв файловой системы — базовый слой ОС, рантайм языка, системные библиотеки, затем твой код и зависимости поверх — упакованная в тарбол с JSON-манифестом и адресуемая по хешу содержимого (дайджест, sha256:…). Когда ты пишешь FROM node:18, ты наследуешь сотни мегабайт чужих бинарей: userland Debian, OpenSSL, glibc, рантайм Node и всё, что они тянут. Твой COPY . . — это тонкий верхний слой. Значимая для безопасности правда в том, что большая часть поверхности атаки типового образа лежит ниже твоей черты — в слоях, которые ты не писал и редко аудируешь.

Это наследование — первая проблема, потому что уязвимости живут в этих нижних слоях. Обзоры публичных образцов регулярно находили от десятков до сотен известных CVE на образ, подавляющее большинство — в пакетах ОС и базовых слоях языка, а не в коде приложения. Критический CVE в OpenSSL или glibc оказывается в твоём образе в тот момент, когда ты собираешь поверх базы, содержащей уязвимую версию, — ты отгрузил его, не написав ни строки уязвимого кода. Так что «безопасен ли мой образ?» — это в основном «что я унаследовал и знаю ли я текущее состояние его CVE?».

Теги плавают; дайджесты пинят

Вторая проблема — идентичность. Тег вроде node:18 или myapp:latest — это изменяемый указатель: сегодня он именует манифест, но владелец реестра (апстрим или любой с правом push) может перенаправить его завтра. FROM node:18 — это не «вот этот конкретный образ», а «то, во что node:18 разрезолвится в момент pull». Две сборки с разницей в неделю могут дать существенно разные образы из идентичного Dockerfile — вот почему «неделю назад собиралось чисто» ничего не говорит о том, что ты запускаешь сейчас.

Фикс — адресовать образы так, как реестр их реально хранит: по дайджесту. FROM node:18@sha256:abc123… пинит точные контент-адресуемые байты; дайджест — это хеш манифеста, поэтому другой образ = другой дайджест, и точка. Пинуй базовые образы по дайджесту в Dockerfile и пинуй задеплоенный образ по дайджесту в манифесте Kubernetes (image: myapp@sha256:…, а не image: myapp:latest). Это делает деплои воспроизводимыми и закрывает атаку перезапуша: даже если кто-то перенаправит тег на отравленный манифест, твоя ссылка по дайджесту за ним не пойдёт. Компромисс реален — дайджесты непрозрачны и не обновляются сами, так что ты меняешь удобство на контроль и заводишь бота (Renovate/Dependabot) для осознанного бампа пинованного дайджеста — что и есть смысл: обновления становятся решениями, а не сюрпризами.

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

Третий контроль бьёт по унаследованной поверхности напрямую: бери минимальную базу, на которой приложение работает. Полная база ubuntu или debian несёт шелл, пакетный менеджер, curl/wget, coreutils и сотни библиотек — каждая потенциальный CVE и каждая удобство для пост-эксплуатации. Прогрессия: debian (≈120 МБ, полный userland) → debian-slim (≈75 МБ, урезанный) → alpine (≈5–8 МБ, musl libc + busybox) → distroless (образы Google: только твоё приложение, его рантайм-зависимости, CA-сертификаты и /etc/passwd — ни шелла, ни пакетного менеджера, ни busybox) → scratch (буквально пустой; для статического бинаря).

Выигрыш двойной. Во-первых, меньше пакетов — меньше CVE отслеживать и патчить: distroless или scratch может нести однозначное число или ноль CVE в ОС против десятков в полной базе, что прямо ужимает беговую дорожку скан-и-пересборки. Во-вторых, и это недооценивают: без шелла в образе атакующий, добившийся RCE, не сделает sh -c, не подтянет curl | sh второй стейдж и не воспользуется обычными living-off-the-land бинарями — он сведён к тому, что даёт его единственный примитив эксплойта. Цена операционная: нельзя kubectl exec дебаг-шелл в distroless под (вместо этого — эфемерные дебаг-контейнеры), а musl-based Alpine может выявить тонкие отличия libc (резолвинг DNS, некоторые glibc-only бинари). Для большинства сервисов компромисс в пользу минимума; тянись к более полной базе только когда упёрся в конкретную стену совместимости.

Скан и пересборка: образ без CVE гниёт на месте

Сканирование — контроль, который все знают, и тот, что чаще всего понимают неверно. Сканер (Trivy, Grype, Clair или встроенный в реестр) читает метаданные пакетов образа, сопоставляет установленные версии с базами уязвимостей (NVD, трекеры безопасности дистрибутивов, GitHub Advisory) и репортит CVE по серьёзности. Зрелое озарение двойное. Во-первых, сканируй на этапе сборки и роняй пайплайн на новые critical — скан, который только крутится на дашборде, куда никто не смотрит, это театр; ценность — в гейте, который вообще не даёт уязвимому образу запушиться. Во-вторых, тоньше: число CVE образа растёт со временем, хотя образ не меняется, потому что новые CVE раскрываются против пакетов, уже находящихся внутри. Образ, который ты сканировал чисто в январе, может нести три новых critical в марте без единого изменённого байта. Так что реальный контроль — не «сканируй однажды», а цикл: пересканируй задеплоенные образы по расписанию против текущей базы и пересобирай на свежей базе, чтобы впитать апстрим-патчи. Пересборка — это то, как фикс реально приходит: пропатченный OpenSSL входит в твой образ только когда ты пересобираешь на базе, его содержащей.

Поэтому же минимальные базы и сканирование усиливают друг друга: чем меньше пакетов ты наследуешь, тем меньше CVE раскроется против тебя позже, так что беговая дорожка пересборки крутится медленнее.

Запускай не от root и доказывай происхождение

Ещё два контроля замыкают цикл. Запускай от не-root пользователя: по умолчанию процесс контейнера работает от root (uid 0) внутри контейнера, и хотя это не root хоста, это ненужная эскалация — задай директиву USER в Dockerfile (или runAsNonRoot: true в поде), чтобы баг процесса попадал на непривилегированного пользователя, сужая радиус поражения чего угодно сломавшегося. Это бесплатно почти для любого приложения и требуется уровнем restricted Pod Security Standard. (Рантайм-харденинг — капабилити, seccomp, read-only корень — это следующий урок; здесь build-time срез лишь: не запекай root.)

Доказывай происхождение подписью. Пин по дайджесту гарантирует, что ты запускаешь конкретный образ; подпись гарантирует, что этот образ пришёл от тебя. С cosign из Sigstore ты подписываешь образ (keyless, через OIDC, так что нет долгоживущего ключа, который утечёт) и прикрепляешь аттестации — SBOM (software bill of materials: полную инвентаризацию зависимостей, чтобы когда выйдет следующий Log4Shell, ты ответил «затронуты ли мы?» за минуты, а не за дни) и заявление о SLSA-провенансе (кто собрал, из какого коммита исходника, на каком сборщике). Затем admission-контроллер в кластере (Kyverno, Sigstore Policy Controller, Connaisseur) проверяет подпись до того, как поду разрешат запуститься, и отклоняет всё неподписанное или подписанное не той личностью. Это звено, что бьёт по компрометации реестра: даже если атакующий запушит вредоносный образ, он не подписан твоей сборочной личностью, так что admission его не пустит.