Блог
Практичний контрольний список безпеки ізоляції 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)
- Docker and Container Isolation
- Chapter 2. Container Hosts and Multi-tenancy | Container Security Guide | OpenShift Container Platform | 3.6 | Red Hat Documentation
- What is Container Escape? - Aqua Security
- Container escape vulnerabilities allow attackers to break out of isolated environments and gain unauthorized access to host systems.
- Enhanced Container Isolation - Docker Docs

