Постигане на истинска изолация за множество наематели в Docker

Резюме

Docker контейнерите споделят хостовото ядро, което може да бъде проблем за сигурността в среди с множество наематели, където наемателите не си вярват взаимно. Тази статия обяснява пропуските в изолацията при стандартните Docker настройки и предоставя конкретни стъпки за укрепване на изолацията чрез Linux namespaces, cgroups, потребителски пространства, seccomp, AppArmor и хардуерна виртуализация. Ще научите как да конфигурирате Docker демони за отделни наематели, да използвате инструменти за пясъчна среда като gVisor или Firecracker за по-силна изолация и да оркестрирате с Kubernetes за многопотребителско използване. Ще разгледаме и избора на правилния доставчик на инфраструктура, който предлага KVM-базирана виртуализация за допълнителен слой на разделяне. Накрая ще имате план за сигурно изпълнение на многопотребителски работни натоварвания с Docker.

Когато хоствате множество наематели на един Docker хост, стандартната изолация на контейнерите—изградена върху Linux namespaces и cgroups—често не е достатъчна. Пробив в контейнер на един наемател може да компрометира целия хост и всички останали контейнери. Този проблем е особено остър в споделен хостинг, SaaS платформи или всяка ситуация, в която ненадежден код се изпълнява заедно с вашия. Добрата новина: можете да наслагвате множество техники за изолация, за да изградите укрепена многопотребителска среда. Това ръководство преминава през шест практически стъпки, от лесни решения като потребителски пространства до напреднали мерки като изпълнение в пясъчна среда и инфраструктурни избори.

Разбиране на стандартната изолация на Docker

Docker използва Linux namespaces, за да изолира процеси, мрежа, файлова система и други ресурси. Cgroups ограничават CPU, памет и I/O. Но те споделят едно ядро—уязвимост в ядрото може да засегне всички контейнери. За истинска многопотребителска среда, особено с ненадеждни наематели, се нуждаете от защита в дълбочина. Както е обсъдено в Проектиране на многопотребителска Docker архитектура: Избор на правилното ниво на изолация, нивата на изолация варират от слаба (само namespace) до силна (хардуерно виртуализирана). Нека започнем от най-слабата.

Стъпка 1: Активирайте потребителски пространства (User Namespaces)

По подразбиране root в контейнер съответства на root на хоста. Пробив в контейнера дава пълен достъп до хоста. Потребителските пространства пренасочват root на контейнера към непотребител извън него. Активирайте го глобално с dockerd --userns-remap=default или за контейнер с --userns=host. Тази проста стъпка елиминира много атаки за повишаване на привилегии. Тествайте приложенията си: някои, които изискват привилегии на ниво хост (например монтиране на файлови системи), може да се счупят. За Drupal или WordPress сайтове обикновено е безопасно.

Стъпка 2: Приложете Seccomp и AppArmor профили

Seccomp ограничава системните извиквания, които контейнерът може да прави. Docker идва с профил по подразбиране, който блокира опасни системни извиквания като mount и reboot. За многопотребителска среда го затегнете още—блокирайте необичайни системни извиквания, които инструментите за пробив използват. По подобен начин AppArmor може да ограничи контейнерните процеси. Създайте персонализиран AppArmor профил, който забранява запис до ядрените интерфейси и ограничава файловите пътища. И двете се задават чрез флагове --security-opt. Комбинирайте ги за слоева защита.

Стъпка 3: Използвайте Docker демони за отделни наематели

Изпълнението на един Docker демон за всички наематели е рисковано—всеки пробив в контейнер може да получи достъп до сокета на демона. Изолирайте демоните за отделни наематели, използвайки Docker-in-Docker (DinD) или отдалечени крайни точки на демона. Например, стартирайте Docker демон в контейнер с --privileged (но това отслабва изолацията). По-добър подход: стартирайте отделни демони на отделни виртуални машини или използвайте експерименталната функция --group на Docker с потребителски пространства. За оркестрация изолацията на базата на Kubernetes namespace е по-практична, както е обхванато в Защита срещу пробив на контейнери: Практическо ръководство за Docker изолация за многопотребителски хостинг.

Стъпка 4: Обмислете изпълнение в пясъчна среда (Sandboxed Runtimes)

Когато самото Linux ядро не е надеждно, използвайте пясъчна среда, която добавя лек VM слой. gVisor (runsc) прихваща системни извиквания и имплементира собствено ядро, докато Firecracker използва микро-VM с хардуерна виртуализация. И двете се интегрират с Docker чрез containerd runtimes. Например, добавете "runtimes": {"runsc": {}} в конфигурацията на Docker демона и стартирайте контейнери с --runtime=runsc. Производителността пада с 5–15%, но изолацията е значително по-силна. Идеални за високо-сигурни многопотребителски настройки.

Стъпка 5: Оркестрирайте с Kubernetes и политики за сигурност

Kubernetes предоставя естествена многопотребителска поддръжка чрез namespaces, Pod Security Standards и NetworkPolicies. Дефинирайте namespaces за отделните наематели с квоти за ресурси и наложете ограничени контексти за сигурност на подове (премахване на всички възможности, само за четене на коренова файлова система). Admission контролери като OPA/Gatekeeper могат да блокират неправилни конфигурации. Ако управлявате много наематели, Kubernetes автоматизира прилагането на изолация. За оркестрация в производствен мащаб вижте Отвъд Docker Compose: Оркестриране на готови за производство контейнеризирани приложения.

Стъпка 6: Изберете правилния хостинг доставчик

Хипервайзорът на вашия инфраструктурен доставчик е важен. Docker върху споделен хостинг (OpenVZ) дава слаба изолация—един наемател може да види процесите на друг. Предпочитайте доставчици, които използват KVM или VMware, които предлагат разделяне на хардуерно ниво. Доставчици като DigitalOcean, Kamatera или AWS предлагат KVM-базирани VPS с посветени ресурси. За bare-metal се уверете, че BIOS виртуализацията е активирана за вложени контейнери. Доставчик, който изолира наемателите на ниво хипервайзор, допълва изолацията на контейнерите. Както е описано в Овладяване на Docker изолация за сигурен и ефективен уеб хостинг, хост операционната система също трябва да бъде укрепена с минимална повърхност за атака.

Предупреждения и компромиси

Всеки допълнителен слой добавя сложност и разходи за производителност. Потребителските пространства могат да счупят томове, монтирани от хоста. Seccomp профилите изискват настройка за всяко приложение. Пясъчните среди като gVisor не поддържат всички системни извиквания—вашето приложение може да не работи. Docker демоните за отделни наематели увеличават паметта. Изберете нивото на изолация, което отговаря на вашия заплашителен модел: за надеждни наематели стандартните namespaces може да са достатъчни; за публични SaaS инвестирайте в пясъчни среди и Kubernetes политики. Тествайте обстойно преди продукция.

Заключение

Истинската изолация за множество наематели в Docker е постижима чрез наслагване на множество функции на ядрото, пясъчни среди и контроли за оркестрация. Започнете с потребителски пространства и seccomp, след това преминете към демони за отделни наематели или пясъчни среди. За голям мащаб Kubernetes предоставя управлявана от политики изолация. Винаги комбинирайте с хост, отделен на ниво хипервайзор, от реномиран доставчик. Никоя отделна техника не е непробиваема, но комбинирането им създава надеждна защита. Вашите наематели ще ви благодарят—и вашият одит за сигурност също.