Топ-5 лучших практик безопасности Docker для защиты ваших приложений

Безопасность Docker начинается до того, как контейнер будет запущен. Ваш образ может содержать уязвимые пакеты, ваш контейнер может работать с большими привилегиями, чем необходимо, или ваш сокет Docker может предоставить злоумышленнику прямой путь к хосту.

Эти пять лучших практик безопасности Docker сосредоточены на контролях, которые имеют наибольшее повседневное значение: доверенные образы, небольшая поверхность выполнения, непривилегированные процессы, ограниченный сетевой доступ и защищенный демон.

1. Регулярно сканируйте образы Docker на уязвимости

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

Почему сканирование образов критически важно

• Выявление известных эксплойтов: Сканеры образов могут обнаруживать общеизвестные уязвимости (CVE) в пакетах операционной системы и зависимостях приложений внутри ваших образов.
• Предотвращение атак на цепочку поставок: Убедитесь, что используемые вами базовые образы не были изменены или не содержат вредоносных нагрузок.
• Поддержание соответствия требованиям: Многие нормативные рамки требуют регулярного сканирования уязвимостей программных компонентов.

Инструменты и методы

Несколько инструментов могут помочь вам сканировать ваши образы Docker:

• Docker Scout: Инструмент анализа образов Docker, доступный через продукты Docker и рабочие процессы CLI в зависимости от вашей настройки.
• Trivy: Простой в использовании сканер с открытым исходным кодом, который находит уязвимости в образах контейнеров, репозиториях Git и многом другом.
• Clair: Еще один инструмент статического анализа уязвимостей с открытым исходным кодом для контейнеров.
• Trivy CLI:

  trivy image your-docker-image:tag
  

Лучшая практика: Интегрируйте сканирование образов в ваш конвейер непрерывной интеграции/непрерывного развертывания (CI/CD). Это гарантирует, что образы сканируются до того, как они будут развернуты в производство, предотвращая попадание уязвимых образов в рабочие среды.

2. Минимизируйте поверхность атаки контейнера, используя минимальные базовые образы

Принцип наименьших привилегий распространяется и на образы контейнеров. Чем меньше и более сфокусирован ваш базовый образ, тем меньше потенциальных уязвимостей он будет содержать и тем сложнее злоумышленнику будет его эксплуатировать.

Почему минимальные образы важны

• Уменьшенное количество уязвимостей: Меньше пакетов означает меньше потенциальных точек входа для злоумышленников.
• Меньший размер: Минимальные образы приводят к более быстрым загрузкам и развертываниям и потребляют меньше места для хранения.
• Более легкое обслуживание: Меньше программного обеспечения для исправления и управления.

Выбор минимальных базовых образов

• alpine Linux: Маленький и популярный, но проверьте совместимость, так как он использует musl libc вместо glibc.
• Distroless образы: Они содержат ваше приложение и зависимости времени выполнения без оболочки или менеджера пакетов. Они уменьшают то, что злоумышленник может использовать после компрометации, но могут усложнить отладку.

Пример: Использование Alpine в качестве базового образа

Вместо:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y --no-install-recommends your-app

Рассмотрите:

FROM alpine:latest
RUN apk add --no-cache your-app

Совет: Устанавливайте только те пакеты и зависимости, которые абсолютно необходимы вашему приложению. Избегайте установки инструментов разработки, оболочек или ненужных утилит в производственных образах.

3. Запускайте контейнеры от имени непривилегированных пользователей

Если образ не указывает другого пользователя, процессы внутри контейнера Docker выполняются от имени root. Если злоумышленник получает возможность выполнения кода в этом контейнере, root внутри контейнера дает ему больше возможностей для изменения файлов, злоупотребления смонтированными томами или объединения компрометации с неправильной конфигурацией Docker или ядра.

Риски запуска от имени root

• Повышение привилегий: Если контейнер скомпрометирован, злоумышленник получает полный root-доступ внутри контейнера. Если контейнер имеет чрезмерные привилегии на хосте, это может привести к компрометации хоста.
• Изменение данных: Пользователи root могут изменять любые файлы в файловой системе контейнера.

Реализация выполнения от имени непривилегированного пользователя

• Создайте выделенного пользователя: В вашем Dockerfile создайте непривилегированного пользователя и группу, а затем переключитесь на этого пользователя перед запуском вашего приложения.
• Установите права доступа к файлам: Убедитесь, что файлы и каталоги приложения принадлежат непривилегированному пользователю.

Пример фрагмента Dockerfile:

# Создайте непривилегированного пользователя и группу
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

# Скопируйте файлы приложения и установите владельца
COPY --chown=appuser:appgroup /app /app

# Переключитесь на непривилегированного пользователя
USER appuser

# Установите рабочую директорию
WORKDIR /app

# Команда для запуска вашего приложения
CMD ["your-app-executable"] 

Предупреждение: Убедитесь, что пользователь, от имени которого запускается ваше приложение, имеет необходимые права доступа к файлам для чтения и записи в требуемые каталоги или файлы. Если нет, ваше приложение может не запуститься или работать неправильно.

4. Реализуйте сетевую сегментацию и принцип наименьших привилегий для взаимодействия контейнеров

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

Преимущества сетевой сегментации

• Ограничение радиуса взрыва: Если один контейнер скомпрометирован, сетевая сегментация может предотвратить его доступ к другим чувствительным контейнерам или службам.
• Контроль потока трафика: Определите, какие контейнеры могут взаимодействовать друг с другом и на каких портах.
• Улучшение уровня безопасности: Применяйте принцип наименьших привилегий для сетевого доступа.

Лучшие практики работы с сетями Docker

• Используйте пользовательские сети: Вместо использования сети bridge по умолчанию создавайте пользовательские сети для каждого приложения или уровня. Пользовательские сети bridge также предоставляют встроенное обнаружение служб на основе DNS по имени контейнера.

  docker network create my-app-network
  docker run --network my-app-network ...
  

• Ограничьте доступ контейнеров: Если фронтенду нужно только вызывать API, поместите эти две службы в одну сеть, а базу данных оставьте в отдельной внутренней сети, доступной только API.
• Используйте правила брандмауэра (на уровне хоста): Реализуйте правила брандмауэра на уровне хоста (например, iptables) для дальнейшего ограничения сетевого трафика к контейнерам и от них.
• Рассмотрите сетевые плагины: Для более продвинутых сетевых политик и сегментации изучите сетевые плагины Docker или платформы оркестрации контейнеров, такие как Kubernetes, которые предлагают сложные сетевые политики.

Совет: Регулярно проверяйте конфигурации сети контейнеров и списки контроля доступа, чтобы убедиться, что они соответствуют вашим требованиям безопасности и принципу наименьших привилегий.

5. Защитите демон Docker и хост

Сам демон Docker является мощным компонентом, который напрямую взаимодействует с операционной системой хоста. Если демон Docker будет скомпрометирован, злоумышленник может получить значительный контроль над всей вашей средой Docker, включая хост-машину.

Защита демона Docker

• Ограничьте доступ к демону: Убедитесь, что сокет демона Docker (/var/run/docker.sock) не доступен ненадежным пользователям или приложениям. Предоставляйте доступ только авторизованным пользователям.
• Используйте TLS для удаленного доступа к демону: Если вы предоставляете API Docker через TCP, защитите его с помощью TLS и аутентификации клиента. Избегайте его предоставления, если у вас нет четкой операционной необходимости.
• Предпочитайте rootless режим, где это уместно: Rootless Docker может снизить риск на уровне хоста для некоторых рабочих нагрузок, хотя у него есть компромиссы в сети и функциональности, которые вы должны протестировать.

Защита хоста Docker

• Поддерживайте ОС хоста в актуальном состоянии: Регулярно исправляйте и обновляйте базовую операционную систему вашего хоста Docker для устранения уязвимостей безопасности.
• Укрепите хост: Примените конфигурации усиления безопасности к хост-машине, такие как отключение ненужных служб, настройка брандмауэров и обеспечение строгого контроля доступа.
• Мониторинг активности хоста: Внедрите надежное ведение журнала и мониторинг для хоста Docker для обнаружения подозрительной активности.
• Используйте инструменты безопасности: Применяйте системы обнаружения вторжений на основе хоста, аудит журналов и мониторинг времени выполнения, где это уместно в вашей среде.
• Откажитесь от ненужных привилегий: Избегайте --privileged, отключайте возможности Linux, которые вам не нужны, и используйте файловые системы только для чтения, где это поддерживается вашим приложением.

Лучшая практика: Регулярно проверяйте конфигурацию демона Docker и уровень безопасности ваших хостов Docker. Рассмотрите использование инструментов сравнительного анализа безопасности, таких как CIS Docker Benchmark, для оценки и улучшения ваших настроек безопасности.

Вывод

Сделайте безопасность Docker частью обычного пути доставки. Сканируйте образы в CI, поддерживайте производственные образы небольшими, запускайте от имени непривилегированного пользователя, изолируйте службы по сети и защищайте хост Docker как высокоценную систему. Начните с одной службы, примените эти контроли, а затем превратите этот шаблон в ваш шаблон по умолчанию.