Безопасность контейнеров.

Безопасность контейнеров охватывает весь жизненный цикл OCI-совместимых контейнеров (Docker, containerd, CRI-O). На этапе сборки команды сканируют образы на CVE и встроенные секреты, подписывают их через Sigstore/Cosign и используют минимальные базовые образы. При распространении реестры защищаются аутентифицированным доступом и проверкой подписей. В runtime ужесточение хоста, изоляция через namespaces/cgroups, seccomp, AppArmor и read-only файловые системы уменьшают поверхность атаки, а admission-контроллеры и eBPF-сенсоры применяют политики и выявляют аномалии.

Контейнеры разделяют ядро хоста, поэтому единственный дефект ядра или runtime способен нарушить изоляцию. CVE-2019-5736 позволяла вредоносному образу перезаписать хостовый бинарник runc через /proc/self/exe, получив выполнение кода с правами root на узле; исправлено в runc 1.0-rc7 и Docker 18.09.2. Уязвимость 2024 года «Leaky Vessels» CVE-2024-21626 утекала внутренний файловый дескриптор (fd/7), указывавший на рабочий каталог хоста до pivot_root, так что установка cwd контейнера в /proc/self/fd/7 позволяла выйти за пределы rootfs (исправлено в runc 1.1.12). Поскольку побег из пода обычно равнозначен компрометации узла, важна эшелонированная защита: сбрасывать capabilities, запускать от не-root, избегать привилегированных и hostPath-монтирований, своевременно патчить runc и рассматривать более строгие песочницы, такие как gVisor или Kata Containers.

flowchart LR
  A[Сборка: скан + подпись образа] --> B[Реестр: аутентификация + проверка подписи]
  B --> C[Admission: отклонять привилегированные/hostPath]
  C --> D[Runtime: seccomp, AppArmor, не-root, caps сброшены]
  D --> E[Обнаружение: алерты eBPF/Falco]
  D -. дефект ядра/runc .-> X[Побег из контейнера на хост]
  X -. смягчается .-> F[Песочница gVisor / Kata]