Блог

Практичний контрольний список безпеки ізоляції Docker для багатоорендного хостингу

Захистіть свій багатоорендний хостинг Docker за допомогою цього практичного списку, який охоплює користувачів без root, можливості, seccomp, простори імен користувачів, обмеження ресурсів та файлові системи лише для читання.

Резюме

Багатоорендний хостинг 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  # if needed

Застереження: Можливості, такі як 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 всередині контейнера, він не матиме спеціальних привілеїв на хості.

Увімкніть це на демоні 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, щоб ваш сайт запрацював за хвилини.

Sources (5)