Практический чек-лист безопасности изоляции Docker для многотенантного хостинга

Краткое описание

Многотенантный хостинг Docker требует надежной изоляции для предотвращения побега из контейнеров. В этой статье представлен практический чек-лист безопасности, охватывающий шесть ключевых областей: запуск от имени не-root, удаление возможностей, применение профилей seccomp, включение переназначения пространства имен пользователей, установка ограничений ресурсов и использование корневых файловых систем только для чтения. Каждый шаг включает конкретный пример конфигурации для Docker Compose. Вы также узнаете о распространенных ошибках, таких как проблемы совместимости ядра с пространствами имен пользователей и компромиссы производительности при применении seccomp. Следуя этому чек-листу, вы можете значительно уменьшить поверхность атаки, не добавляя излишней сложности. Статья завершается рекомендуемой базовой конфигурацией для производственных многотенантных сред.

Если вы управляете многотенантной средой Docker, призрак атаки с побегом из контейнера не дает вам спать по ночам. Одна эксплойтация ядра может вырваться из контейнера и предоставить злоумышленнику неограниченный доступ к хосту и данным всех других арендаторов. Хотя Docker предоставляет мощные примитивы изоляции — пространства имен, cgroups и возможности — неправильная конфигурация оставляет пробелы. Эта статья представляет пошаговый чек-лист безопасности, который вы можете применить сегодня. Каждый шаг включает рабочий фрагмент Docker Compose и ключевые предостережения. В итоге вы получите усиленный базовый уровень, который балансирует безопасность и производительность.

1. Запуск контейнеров от имени не-root пользователя

Контейнеры по умолчанию запускаются от имени root внутри контейнера. Если злоумышленник получает root в контейнере, у него есть преимущество для побега. Всегда определяйте не-root пользователя в вашем Dockerfile.

FROM alpine:3.18
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

В Compose вы также можете установить пользователя напрямую:

services:
  app:
    image: myapp
    user: "1000:1000"

Предостережение: Некоторые приложения требуют root для легитимных операций (например, привязка к портам ниже 1024). Используйте CAP_NET_BIND_SERVICE вместо запуска всего контейнера от root. Для более глубокого изучения основ изоляции см. наше руководство по достижению истинной многотенантной изоляции в Docker.

2. Удаление всех возможностей и добавление только необходимых

Возможности Linux предоставляют контейнерам детальные привилегии. По умолчанию Docker предоставляет набор возможностей. Удалите все и предоставьте только необходимые.

services:
  app:
    image: myapp
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # если необходимо

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

3. Применение профиля seccomp

Seccomp (режим безопасных вычислений) фильтрует системные вызовы, доступные контейнеру. Docker поставляется с профилем seccomp по умолчанию, который блокирует опасные системные вызовы, такие как clone с определенными флагами. Вы можете дополнительно настроить его.

services:
  app:
    image: myapp
    security_opt:
      - seccomp=/path/to/custom-profile.json

Усиленный профиль может блокировать unshare, ptrace и mount. Начните с профиля Docker по умолчанию и ограничьте дальше. Предостережение: Слишком строгие профили могут нарушить работу приложений. Тщательно тестируйте в промежуточной среде. Подробнее о защите от побега из контейнера читайте в статье защита от побега из контейнера.

4. Включение переназначения пространства имен пользователей

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

Включите это в демоне Docker, отредактировав /etc/docker/daemon.json:

{
  "userns-remap": "default"
}

Затем перезапустите Docker. Предостережение: Переназначение пространства имен пользователей имеет два недостатка: оно нарушает монтирование томов, если не настроено тщательно (файлы принадлежат переназначенному пользователю) и несовместимо с некоторыми драйверами хранения, такими как overlay2 на старых ядрах. Тщательно тестируйте.

5. Установка ограничений ресурсов с помощью cgroups

Ограничения ресурсов предотвращают атаку типа «отказ в обслуживании» со стороны скомпрометированного контейнера на хост. Используйте cgroups для ограничения CPU, памяти и дискового ввода-вывода.

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

Для Docker Compose v3 используйте раздел deploy (работает с swarm или compose v2). Для обычного Docker используйте --memory и --cpus. Предостережение: Слишком низкие ограничения могут привести к OOM-убийствам. Мониторьте использование и корректируйте соответственно.

6. Использование корневой файловой системы только для чтения

Корневая файловая система только для чтения предотвращает запись злоумышленниками вредоносных двоичных файлов или изменение конфигурационных файлов внутри контейнера.

services:
  app:
    image: myapp
    read_only: true
    tmpfs:
      - /tmp:noexec,nosuid,size=64m

Монтируйте tmpfs на каталоги, которым требуется доступ на запись (например, /tmp). Это делает все записываемые данные эфемерными. Предостережение: Некоторые приложения требуют постоянного хранения; используйте для этого именованные тома.

Распространенные ошибки

• Совместимость с ядром: Переназначение пространства имен пользователей и некоторые правила seccomp требуют современного ядра Linux (4.14+). Проверьте версию вашего ядра.
• Влияние на производительность: Seccomp и пространства имен пользователей добавляют небольшие накладные расходы, но для большинства рабочих нагрузок это незначительно. Проведите бенчмаркинг вашего приложения.
• Сложность: Внедрение всех шести мер одновременно может привести к поломкам. Применяйте их по одной, тестируйте каждое изменение.

Для более широкого взгляда на шаблоны оркестрации см. наше руководство по проектированию многотенантной архитектуры Docker.

Заключение

Безопасный многотенантный хост Docker не требует экзотических инструментов — только правильного использования встроенных функций Docker. Начните с не-root пользователя, удалите все возможности, примените профиль seccomp, включите переназначение пространства имен пользователей, установите ограничения ресурсов и используйте файловую систему только для чтения. Этот чек-лист формирует надежный базовый уровень, который блокирует наиболее распространенные техники побега. После внедрения запустите инструменты безопасности, такие как docker-bench-security, чтобы проверить конфигурацию. Помните: безопасность — это процесс, а не продукт. По мере появления новых уязвимостей ядра пересматривайте свои настройки. Для автоматических целевых страниц, демонстрирующих вашу услугу хостинга, используйте Pagenza, чтобы запустить сайт за минуты.