AppArmor & SELinux для контейнеров
Тема дорожной карты · Docker & Containers
AppArmor и SELinux — это системы Mandatory Access Control (MAC), которые ограничивают доступ процесса контейнера к ресурсам, даже если он запущен с правами root. Эти системы являются важным инструментом для обеспечения безопасности контейнерных приложений, особенно в условиях, когда контейнеры могут быть запущены в многопользовательской среде.
Как это работает
AppArmor и SELinux имеют несколько уровней безопасности: контент образа (включая CVE в базовых системах, коде и зависимостях), процесс сборки (недоверенные RUN-команды, утечки секретов), runtime (root внутри контейнера, capabilities, seccomp, AppArmor/SELinux), и хост (обновления ядра, экспозиция daemon-сокета). Hardening начинается с минимального базового образа (например, distroless, alpine или scratch), запуска не-root (USER 10000:10000), и сброса capabilities (--cap-drop ALL --cap-add NET_BIND_SERVICE).
Когда применять
Применение security-baseline с самого начала жизненного цикла проекта — это лучшая практика. Сканирование образов на наличие уязвимостей должно быть частью каждого цикла CI через инструменты, такие как Trivy или Grype, и все билды с критическими уязвимостями (CRITICAL CVE) должны быть отклонены. Корневая файловая система должна быть в режиме read-only там, где это возможно, особенно если приложение поддерживает это. Никогда не следует монтировать Docker daemon socket в контейнер, за исключением явно изолированных CI-раннеров. Для многопользовательских нагрузок следует использовать более глубокое sandboxing (например, gVisor или Kata Containers); стандартные namespaces могут быть недостаточными.
Типичные ошибки
Типичные ошибки при использовании AppArmor и SELinux в контейнерах включают запуск всего под правами root внутри контейнера ("контейнер же изолирован" — до kernel-CVE или docker.sock); игнорирование CVE ("у нас этот эндпойнт не открыт" — защита на глубине); использование опции --privileged, чтобы какая-то библиотека заработала (это предоставляет полные права на уровне ядра); хранение API-ключей через ENV (они могут быть видны в истории команд). Аудит образов должен проводиться раз в квартал, даже если код приложения не менялся.