Полное руководство по безопасности Docker: от основ до продвинутых практик для production

Docker революционизировал процесс разработки и поставки ПО, но вместе с удобством принес и новую поверхность для атаки. Контейнер — это не виртуальная машина, и его изоляция по умолчанию имеет свои границы. Безопасность Docker-окружения — это многоуровневая дисциплина, охватывающая образы, runtime, хостовую систему и оркестрацию. Данное руководство проведет вас по всем критическим аспектам.

**Уровень 1: Безопасность образов (Image Security).**
Образ — это фундамент. Уязвимый образ делает бессмысленной все остальные защиты.
*  **Минималистичные базовые образы:** Начинайте с `alpine`, `distroless` или `scratch`. Образ `ubuntu:latest` или `centos:latest` содержит сотни пакетов, большинство из которых приложению не нужны, но увеличивают attack surface. Чем меньше пакетов, тем меньше потенциальных уязвимостей.
*  **Многоэтапная сборка (Multi-stage build):** Используйте этот паттерн, чтобы в финальный образ попадали только скомпилированные бинарники и необходимые зависимости, а не компиляторы, исходный код и промежуточные артефакты.
*  **Сканирование на уязвимости:** Интегрируйте сканирование образов (Trivy, Grype, Docker Scout, Snyk) в CI/CD-пайплайн. Блокируйте сборку, если обнаружены критические CVE (Common Vulnerabilities and Exposures). Помните, что нужно сканировать не только базовый образ, но и все устанавливаемые пакеты.
*  **Подписывание образов (Docker Content Trust):** Включайте DCT, чтобы гарантировать, что вы получаете образы из доверенного источника (подписанные издателем) и они не были изменены при передаче. Это защита от атак типа "man-in-the-middle".
*  **Не храните секреты в образах:** Никогда не используйте ARG или ENV для паролей, API-ключей, если они затем попадают в финальные слои. Используйте Docker Secrets (в Swarm) или внешние системы (HashiCorp Vault, AWS Secrets Manager), передавая данные в runtime.

**Уровень 2: Безопасность runtime контейнера.**
Как контейнер ведет себя во время выполнения.
*  **Запуск от непривилегированного пользователя:** По умолчанию контейнеры запускаются от root. Создавайте в Dockerfile отдельного пользователя (`USER 1000`) и запускайте приложение от его имени. Это ограничивает ущерб в случае компрометации приложения.
*  **Read-only корневая файловая система:** Запускайте контейнер с флагом `--read-only`. Это предотвратит модификацию вредоносным ПО или злоумышленником файлов внутри контейнера. Если приложению нужно писать, монтируйте том только в конкретную директорию (`--tmpfs` для /tmp или `-v` для данных).
*  **Ограничение возможностей (Linux Capabilities):** Ядро Linux предоставляет контейнеру набор привилегий (capabilities). Отзовите все ненужные: `--cap-drop=ALL --cap-add=NET_BIND_SERVICE`. Например, `CAP_SYS_ADMIN` дает почти root-права внутри namespace.
*  **AppArmor и SELinux:** Используйте профили безопасности Mandatory Access Control (MAC). AppArmor проще в настройке (можно создать профиль, запрещающий, например, запись в `/proc`). SELinux обеспечивает более тонкую гранулярность.
*  **seccomp-профили:** Ограничивайте системные вызовы (syscalls), которые может выполнять контейнер. Используйте строгий дефолтный профиль Docker (`--security-opt seccomp=/path/to/profile.json`), запрещающий опасные вызовы вроде `clone()` с флагами создания новых namespace.

**Уровень 3: Безопасность хоста (Host Security).**
Скомпрометированный хост означает компрометацию всех контейнеров.
*  **Актуальный Docker Daemon и ядро:** Регулярно обновляйте и демон, и ОС хоста. Уязвимости, такие как CVE-2019-5736 (runC), критичны.
*  **Отдельный пользователь для Docker group:** Помните, что пользователь, состоящий в группе `docker`, получает root-доступ к хосту. Минимизируйте количество таких пользователей.
*  **Аудит демона Docker:** Включите аудит событий Docker (`dockerd`): `auditctl -w /usr/bin/dockerd -k docker`. Это поможет отслеживать подозрительные команды.
*  **Мониторинг в реальном времени:** Используйте инструменты вроде Falco (от Sysdig, теперь CNCF). Falco анализирует поведение контейнеров и хоста на уровне ядра, обнаруживая аномалии: запуск оболочки в production-контейнере, неожиданные исходящие сетевые соединения, запись в системные директории.
*  **Защита сокета демона:** Сокет `/var/run/docker.sock` — это API для управления Docker. Его монтирование в контейнер (`-v /var/run/docker.sock:/var/run/docker.sock`) дает контейнеру полный контроль над хостом. Делайте это только в абсолютно доверенных контейнерах (например, CI-агентах) и с большой осторожностью.

**Уровень 4: Сетевая безопасность и оркестрация.**
*  **Изоляция сетей:** Не используйте сетевой режим `host` без крайней необходимости. Создавайте изолированные bridge-сети Docker и соединяйте только необходимые контейнеры. В Docker Compose и оркестраторах это делается декларативно.
*  **Безопасность в Kubernetes:** Если вы используете Kubernetes (наиболее популярный оркестратор), подключайте дополнительные слои:
 *  **Pod Security Standards/Admission Controllers:** Настройте политики (например, через Pod Security Admission), которые запрещают запуск привилегированных подов, монтирование сокета Docker и т.д.
 *  **Network Policies:** Реализуйте правила брандмауэра между подами, чтобы ограничить трафик по принципу "запрещено все, кроме явно разрешенного".
 *  **SecurityContext:** Задавайте на уровне пода или контейнера ограничения (user ID, capabilities, SELinux options).
 *  **Сканирование на соответствие CIS Benchmark:** Регулярно проверяйте конфигурацию кластера Kubernetes на соответствие стандартам безопасности CIS.

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