Безопасность образов и сканирование

К концу урока ты поймёшь, какие именно четыре решения закаляют образ, почему зелёный CI-скан не равен гарантии безопасности и что продовый пайплайн должен делать иначе, чем сборочный.

Attack surface — это то, что ты отгружаешь

Каждый байт в образе — это то, что атакующий сможет использовать, оказавшись внутри контейнера. Полная база node:18 или python:3.12 — это целый userland Debian или Ubuntu: шелл, apt, curl, bash, десятки системных библиотек, пакетный менеджер — сотни пакетов, каждый из которых — строка в CVE-базе (база известных уязвимостей, Common Vulnerabilities and Exposures). Ты ничего из этого не просил; оно пришло вместе с удобством FROM node:18. Поэтому первый и самый большой рычаг безопасности образа — не сканер и не политика, а нести меньше.

Три движения сжимают attack surface. Slim-варианты (node:22-slim) обрезают базовую ОС примерно до того, что нужно рантайму. Distroless-образы (gcr.io/distroless/*) идут дальше: только твоё приложение плюс его прямые runtime-библиотеки — без шелла, без пакетного менеджера, без apt. Multi-stage сборки гарантируют, что компиляторы, dev-зависимости и кэши apt, которыми ты собирал артефакт, вообще не попадут в финальный стейдж. Выигрыш прямой: меньше установленных пакетов — меньше CVE для триажа, меньше образ для pull и хранения, и куда меньше у атакующего, который получил шелл, — потому что в distroless шелла, в который можно попасть, попросту нет.

# syntax=docker/dockerfile:1
FROM node:22 AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

# Distroless финальный стейдж: приложение + runtime-библиотеки, без шелла, без apt
FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
# Distroless поставляет nonroot-пользователя; не гоняй под root
USER nonroot
CMD ["dist/server.js"]

Три варианта базы меняют attack surface на удобство:

Гоняй non-root и пинни то, что гоняешь

По умолчанию процесс контейнера работает под root внутри своего namespace. Этот root в чём-то ограничен, но это всё равно неправильный дефолт: если атакующий пробьётся в процесс — через баг приложения, RCE в зависимости, неправильно настроенный mount — он наследует root, а root плюс баг ядра, или беспечный флаг --privileged, или записываемый host bind mount — это путь к эскалации за пределы контейнера. Гайд самого Docker прямолинеен: если сервис может работать без привилегий, используй USER, чтобы перейти на non-root пользователя. Добавь явного непривилегированного пользователя и переключись на него до CMD. Соедини это с read-only корневой файловой системой (--read-only, с tmpfs для немногих путей, которым реально нужна запись), чтобы скомпрометированный процесс не смог положить бинарник или переписать твоё приложение на диске.

# Создай и переключись на непривилегированного пользователя до CMD
RUN addgroup --system app && adduser --system --ingroup app app
USER app
# В рантайме запри корневую файловую систему read-only:
#   docker run --read-only --tmpfs /tmp myimage

Вторая дисциплина — пиннинг по digest, а не по тегу. Тег вроде node:22 — это подвижный указатель: издатель может, и делает это, перенаправить его на новый образ при каждой пересборке. Значит, FROM node:22 не воспроизводим: две сборки с разницей в неделю могут скачать два разных base image, а :latest — худший из всех, тихо съезжает под тобой. Digest (node:22@sha256:...) — это неизменяемый хэш содержимого одного точного образа; пиннишь на него — и каждая сборка, каждая машина, каждый CI-прогон получают байт-в-байт одинаковые байты, и у тебя есть фиксированная мишень для скана и аудита. Цена в том, что digest надо осознанно поднимать, чтобы получить upstream-патчи, — и именно поэтому важно сканирование со временем (ниже).

Сканирование: на сборке и навсегда после

Сканер (Docker Scout, Trivy, Grype) строит software bill of materials — SBOM (реестр всего программного обеспечения образа с версиями), полную опись каждого OS-пакета и языковой зависимости в образе с версиями — и сопоставляет эту опись с непрерывно обновляемой базой уязвимостей, чтобы точно указать CVE в твоих слоях и пакетах. Встрой его в CI как гейт: роняй сборку на новых critical/high находках, чтобы уязвимый образ не отгрузился. SBOM — ещё и твой provenance и аудиторская запись: когда выйдет следующий громкий CVE, ты отвечаешь на «затронуты ли мы?» запросом к SBOM, а не гаданием.

# Опись + сводка уязвимостей (Docker Scout)
docker scout quickview my-app:1.4.0
docker scout cves my-app:1.4.0

# Сгенерировать SBOM для аудита / provenance
docker scout sbom my-app:1.4.0

# То же на Trivy, с гейтом CI по critical/high
trivy image --severity CRITICAL,HIGH --exit-code 1 my-app:1.4.0

Сеньорский failure mode — считать скан на сборке всей работой. Зелёный скан — это снимок, а не гарантия. Новые CVE раскрывают ежедневно против пакетов, которые уже внутри твоего отгруженного образа; образ, чистый на сборке, через месяц может быть критичным без единого изменения кода — ровно как в хуке. Поэтому сканирование должно бежать по расписанию против задеплоенных образов, а не только в той сборке, что их породила, и алерт должен уходить к тому, кто может отгрузить пропатченный digest. Пересканируй образы в реестре ночами; считай «никто не пересканировал» настоящей уязвимостью.