Досягнення істинної ізоляції кількох орендарів у Docker

Резюме

Контейнери Docker спільно використовують ядро хоста, що може бути проблемою безпеки для середовищ з кількома орендарями, де орендарі можуть не довіряти один одному. Ця стаття пояснює прогалини в ізоляції стандартних налаштувань Docker і надає конкретні кроки для посилення ізоляції за допомогою просторів імен Linux, cgroups, просторів імен користувачів, seccomp, AppArmor та апаратної віртуалізації. Ви дізнаєтесь, як налаштувати демони Docker для кожного орендаря, використовувати інструменти пісочниці, такі як gVisor або Firecracker, для посилення ізоляції та оркеструвати за допомогою Kubernetes для багатоорендарності. Ми також розглянемо вибір правильного постачальника інфраструктури, який пропонує віртуалізацію на основі KVM для додаткового рівня розділення. Наприкінці ви матимете план для запуску безпечних багатоорендарних навантажень з Docker.

При розміщенні кількох орендарів на одному хості Docker стандартна ізоляція контейнерів, побудована на просторах імен Linux та cgroups, часто недостатня. Втеча з контейнера одного орендаря може скомпрометувати весь хост та всі інші контейнери. Ця проблема особливо гостра в спільному хостингу, платформах SaaS або будь-яких сценаріях, де ненадійний код виконується поруч з вашим. Хороша новина: ви можете поєднати кілька технік ізоляції для створення посиленого багатоорендарного середовища. Цей посібник проводить через шість практичних кроків, від простих рішень, як простори імен користувачів, до передових заходів, таких як ізольовані середовища виконання та вибір інфраструктури.

Розуміння стандартної ізоляції Docker

Docker використовує простори імен Linux для ізоляції процесів, мережі, файлової системи та інших ресурсів. Cgroups обмежують CPU, пам'ять та I/O. Але вони спільно використовують одне ядро — вразливість у ядрі може вплинути на всі контейнери. Для справжньої багатоорендарності, особливо з ненадійними орендарями, потрібна ешелонована оборона. Як обговорювалося в Проектування багатоорендарної архітектури Docker: вибір правильного рівня ізоляції, рівні ізоляції варіюються від слабких (лише простір імен) до сильних (апаратна віртуалізація). Почнемо з найслабшого.

Крок 1: Увімкнення просторів імен користувачів

За замовчуванням root всередині контейнера відображається на root на хості. Втеча з контейнера дає повний доступ до хоста. Простори імен користувачів перепризначають root контейнера на непривілейованого користувача ззовні. Увімкніть це глобально за допомогою dockerd --userns-remap=default або для окремого контейнера за допомогою --userns=host. Цей простий крок усуває багато атак підвищення привілеїв. Протестуйте свої застосунки: деякі, що вимагають привілеїв рівня хоста (наприклад, монтування файлових систем), можуть не працювати. Для сайтів Drupal або WordPress це зазвичай безпечно.

Крок 2: Застосування профілів Seccomp та AppArmor

Seccomp обмежує системні виклики, які може робити контейнер. Docker постачається зі стандартним профілем seccomp, який блокує небезпечні системні виклики, такі як mount та reboot. Для багатоорендарного середовища посильте його далі — заблокуйте рідкісні системні виклики, які використовують інструменти для втечі. Аналогічно, AppArmor може обмежувати процеси контейнера. Створіть власний профіль AppArmor, який забороняє запис до інтерфейсів ядра та обмежує шляхи до файлів. Обидва налаштовуються за допомогою прапорців --security-opt. Поєднуйте їх для ешелонованого захисту.

Крок 3: Використання демонів Docker для кожного орендаря

Запуск одного демона Docker для всіх орендарів ризикований — будь-яка втеча з контейнера може отримати доступ до сокета демона. Ізолюйте демони для кожного орендаря за допомогою Docker-in-Docker (DinD) або віддалених кінцевих точок демона. Наприклад, запустіть демон Docker всередині контейнера з --privileged (але це послаблює ізоляцію). Кращий підхід: запускайте окремі демони на окремих віртуальних машинах або використовуйте експериментальну функцію --group Docker з просторами імен користувачів. Для оркестрації більш практична ізоляція на основі просторів імен Kubernetes, як описано в Захист від втечі з контейнера: практичний посібник з ізоляції Docker для багатоорендарного хостингу.

Крок 4: Розгляд ізольованих середовищ виконання

Коли саме ядро Linux є ненадійним, використовуйте ізольоване середовище виконання, яке додає легкий шар віртуальної машини. gVisor (runsc) перехоплює системні виклики та реалізує власне ядро, тоді як Firecracker використовує мікро-ВМ з апаратною віртуалізацією. Обидва інтегруються з Docker через середовища виконання containerd. Наприклад, додайте "runtimes": {"runsc": {}} до конфігурації демона Docker та запускайте контейнери з --runtime=runsc. Накладні витрати продуктивності становлять 5–15%, але ізоляція значно сильніша. Ідеально для високобезпечних багатоорендарних установок.

Крок 5: Оркестрація з Kubernetes та політиками безпеки

Kubernetes надає вбудовану багатоорендарність через простори імен, стандарти безпеки подів та мережеві політики. Визначте простори імен для кожного орендаря з квотами ресурсів та застосовуйте обмежені контексти безпеки подів (скидання всіх можливостей, файлова система лише для читання). Адмісійні контролери, такі як OPA/Gatekeeper, можуть блокувати неправильні конфігурації. Якщо ви керуєте багатьма орендарями, Kubernetes автоматизує забезпечення ізоляції. Для оркестрації виробничого масштабу зверніться до Beyond Docker Compose: оркестрація готових до виробництва контейнеризованих застосунків.

Крок 6: Вибір правильного хостинг-провайдера

Гіпервізор вашого постачальника інфраструктури має значення. Docker на спільному хостингу (OpenVZ) дає слабку ізоляцію — один орендар може бачити інші процеси. Віддавайте перевагу провайдерам, які використовують KVM або VMware, що забезпечують розділення на рівні апаратного забезпечення. Постачальники, такі як DigitalOcean, Kamatera або AWS, пропонують VPS на основі KVM з виділеними ресурсами. Для фізичних серверів переконайтеся, що віртуалізація на рівні BIOS увімкнена для вкладених контейнерів. Провайдер, який ізолює орендарів на рівні гіпервізора, доповнює ізоляцію ваших контейнерів. Як детально описано в Освоєння ізоляції Docker для безпечного та ефективного веб-хостингу, ОС хоста також має бути посилена з мінімальною поверхнею атаки.

Застереження та компроміси

Кожен додатковий шар додає складність та знижує продуктивність. Простори імен користувачів можуть порушити роботу змонтованих томів хоста. Профілі Seccomp потребують налаштування під кожен застосунок. Ізольовані середовища виконання, такі як gVisor, не підтримують усі системні виклики — ваш застосунок може не працювати. Демони Docker для кожного орендаря збільшують споживання пам'яті. Вибирайте рівень ізоляції, який відповідає вашій моделі загроз: для довірених орендарів може бути достатньо стандартних просторів імен; для публічного SaaS інвестуйте в пісочниці та політики Kubernetes. Ретельно тестуйте перед виробництвом.

Висновок

Справжня багатоорендарна ізоляція в Docker досяжна шляхом поєднання кількох функцій ядра, ізольованих середовищ виконання та засобів оркестрації. Почніть з просторів імен користувачів та seccomp, потім переходьте до демонів для кожного орендаря або ізольованих середовищ виконання. Для великих масштабів Kubernetes забезпечує ізоляцію на основі політик. Завжди поєднуйте з хостом, розділеним на рівні гіпервізора, від надійного постачальника. Жодна окрема техніка не є абсолютно надійною, але їх комбінування створює надійний захист. Ваші орендарі будуть вдячні — і ваш аудит безпеки також.