Linux Capabilities (--cap-drop)

Тема дорожной карты · Docker & Containers

Linux Capabilities представляют собой механизм, который позволяет разбить полные привилегии root на более мелкие и управляемые единицы. Это позволяет ограничить доступ к определённым системным функциям, что повышает безопасность при работе с контейнерами. В Docker по умолчанию используется ограниченный набор capabilities, но для повышения уровня безопасности рекомендуется использовать опцию --cap-drop=ALL и добавлять только необходимые capabilities, такие как --cap-add=NET_BIND_SERVICE для биндинга порта с номером меньше 1024. Просмотр текущих capabilities можно выполнить с помощью команд docker inspect или getpcaps внутри контейнера. Однако следует быть осторожным с использованием опции --privileged, так как она возвращает все capabilities и отключает seccomp/AppArmor, что делает контейнер практически эквивалентным root-правам и почти никогда не требуется, кроме случаев с вложенным Docker или низкоуровневым доступом к устройствам. Для повышения безопасности рекомендуется использовать --cap-drop=ALL вместе с непривилегированным пользователем (USER).

Как это работает

Linux Capabilities (--cap-drop) имеет несколько уровней защиты: контент образа (включая CVE в базовых системах, коде и зависимостях), процесс сборки (недоверенные RUN-команды, утечки секретов), runtime (использование root внутри контейнера, capabilities, seccomp, AppArmor/SELinux) и хост (обновления ядра, экспозиция daemon-сокета). Для упрочнения системы безопасности рекомендуется начинать с минимального базового образа (например, distroless, alpine или scratch), запускать контейнер не под root (USER 10000:10000), а также сбрасывать capabilities (--cap-drop ALL --cap-add NET_BIND_SERVICE).

Когда применять

Применение security-baseline с самого начала разработки проекта является ключевым моментом, так как попытка ретрофита безопасности в уже работающем проекте может быть болезненной и трудоёмкой. Рекомендуется сканировать образы каждый раз через CI с помощью инструментов, таких как Trivy или Grype, и отклонять сборки, если обнаруживаются критические CVE. Также следует использовать опцию read-only для корневой файловой системы там, где это возможно, и никогда не монтировать Docker daemon socket в контейнер, кроме явно изолированных CI-раннеров. Для многоконтейнерных нагрузок рекомендуется использовать более глубокую изоляцию (например, gVisor, Kata Containers), так как стандартные namespaces могут быть недостаточными.

Типичные ошибки

Типичные ошибки при использовании Linux Capabilities (--cap-drop) включают в себя следующие: использование root внутри контейнера ("контейнер же изолирован" — до обнаружения kernel-CVE или docker.sock); игнорирование CVE ("у нас этот эндпойнт не открыт" — защита на глубоком уровне требует исправления всех уязвимостей); использование --privileged, чтобы какая-то библиотека заработала (это эквивалентно root-правам на уровне ядра); использование API-ключей через ENV (ключи сохраняются в истории команд). Рекомендуется проводить аудит образов раз в квартал, даже если код приложения не меняется.

Связанные понятия

Полезные ресурсы