Dosažení skutečné izolace více tenantů v Dockeru

Shrnutí

Dockerové kontejnery sdílejí hostitelský kernel, což může být bezpečnostní problém pro prostředí s více tenanty, kde si tenanté nemusí navzájem důvěřovat. Tento článek vysvětluje mezery v izolaci ve výchozím nastavení Dockeru a poskytuje konkrétní kroky k posílení izolace pomocí Linuxových jmenných prostorů, cgroups, uživatelských jmenných prostorů, seccomp, AppArmor a hardwarové virtualizace. Naučíte se, jak konfigurovat Docker daemony pro jednotlivé tenanty, používat sandboxovací nástroje jako gVisor nebo Firecracker pro silnější izolaci a orchestrátorovat pomocí Kubernetes pro více tenanců. Také se podíváme na výběr správného poskytovatele infrastruktury, který nabízí virtualizaci založenou na KVM pro další vrstvu oddělení. Na konci budete mít plán pro bezpečný provoz více tenantů s Dockerem.

Při hostování více tenantů na jednom Docker hostiteli výchozí izolace kontejnerů – postavená na Linuxových jmenných prostorech a cgroups – často nestačí. Únik kontejneru v jednom tenantovi by mohl ohrozit celý hostitel a všechny ostatní kontejnery. Tento problém je obzvláště akutní ve sdíleném hostingu, SaaS platformách nebo v jakémkoli scénáři, kde nedůvěryhodný kód běží vedle vašeho vlastního. Dobrá zpráva: můžete naskládat několik izolačních technik k vybudování odolného multi-tenant prostředí. Tento průvodce vás provede šesti praktickými kroky, od snadných opatření jako uživatelské jmenné prostory až po pokročilá opatření jako sandboxované runtime a volby infrastruktury.

Porozumění výchozí izolaci Dockeru

Docker používá Linuxové jmenné prostory k izolaci procesů, sítě, souborového systému a dalších zdrojů. Cgroups omezují CPU, paměť a I/O. Všechny ale sdílejí jediný kernel – zranitelnost v kernelu může ovlivnit všechny kontejnery. Pro skutečnou multi-tenant architekturu, zejména s nedůvěryhodnými tenanty, potřebujete obranu do hloubky. Jak je popsáno v Návrh multi-tenant architektury Dockeru: Volba správné úrovně izolace, úrovně izolace sahají od slabé (pouze jmenné prostory) po silnou (hardwarově virtualizovanou). Pojďme stavět od nejslabší.

Krok 1: Povolení uživatelských jmenných prostorů

Ve výchozím nastavení je root uvnitř kontejneru mapován na root v hostiteli. Únik z kontejneru poskytne plný přístup k hostiteli. Uživatelské jmenné prostory přemapují root kontejneru na uživatele bez rootovských práv mimo kontejner. Povolte je globálně pomocí dockerd --userns-remap=default nebo pro konkrétní kontejner pomocí --userns=host. Tento jednoduchý krok eliminuje mnoho útoků na eskalaci oprávnění. Otestujte své aplikace: některé, které vyžadují oprávnění na úrovni hostitele (např. připojování souborových systémů), mohou selhat. Pro Drupal nebo WordPress weby je to obvykle bezpečné.

Krok 2: Použití profilů Seccomp a AppArmor

Seccomp omezuje systémová volání, která může kontejner provádět. Docker dodává výchozí seccomp profil, který blokuje nebezpečná syscall jako mount a reboot. Pro multi-tenant prostředí ho zpřísněte – blokujte neobvyklá syscall, která používají nástroje pro únik. Podobně AppArmor může omezit procesy kontejneru. Vytvořte vlastní AppArmor profil, který zakáže zápis do jaderných rozhraní a omezí cesty k souborům. Obojí se nastavuje pomocí přepínačů --security-opt. Kombinujte je pro vrstevnatou obranu.

Krok 3: Použití Docker daemonů pro jednotlivé tenanty

Spuštění jediného Docker daemona pro všechny tenanty je riskantní – jakýkoli únik z kontejneru by mohl získat přístup k socketu daemona. Izolujte daemony pro jednotlivé tenanty pomocí Docker-in-Docker (DinD) nebo vzdálených koncových bodů daemona. Například spusťte Docker daemon uvnitř kontejneru s --privileged (ale to oslabuje izolaci). Lepší přístup: spouštějte samostatné daemony na samostatných VM nebo použijte experimentální funkci Dockeru --group s uživatelskými jmennými prostory. Pro orchestrace je izolace založená na jmenných prostorech Kubernetes praktičtější, jak je popsáno v Obrana proti úniku z kontejneru: Praktický průvodce izolací Dockeru pro multi-tenant hosting.

Krok 4: Zvažte sandboxované runtime

Když samotný Linuxový kernel není důvěryhodný, použijte sandboxovaný runtime, který přidá lehkou VM vrstvu. gVisor (runsc) zachycuje syscally a implementuje vlastní kernel, zatímco Firecracker používá mikro-VM s hardwarovou virtualizací. Oba se integrují s Dockerem přes containerd runtime. Například přidejte "runtimes": {"runsc": {}} do konfigurace Docker daemona a spouštějte kontejnery s --runtime=runsc. Výkonnostní režie je 5–15 %, ale izolace je mnohem silnější. Ideální pro vysoce bezpečná multi-tenant prostředí.

Krok 5: Orchestrace s Kubernetes a bezpečnostními politikami

Kubernetes poskytuje nativní multi-tenant architekturu prostřednictvím jmenných prostorů, Pod Security Standards a NetworkPolicies. Definujte jmenné prostory pro jednotlivé tenanty s kvótami zdrojů a vynucujte omezené bezpečnostní kontexty podů (odebrat všechny capabilities, jen pro čtení root filesystem). Přijímací kontroléry jako OPA/Gatekeeper mohou blokovat chybné konfigurace. Pokud spravujete mnoho tenantů, Kubernetes automatizuje vynucování izolace. Pro orchestrátorování v produkčním měřítku se podívejte na Kromě Docker Compose: Orchestrování produkčně připravených kontejnerizovaných aplikací.

Krok 6: Výběr správného poskytovatele hostingu

Hypervizor vašeho poskytovatele infrastruktury je důležitý. Docker na sdíleném hostingu (OpenVZ) poskytuje slabou izolaci – jeden tenant může vidět procesy ostatních. Preferujte poskytovatele používající KVM nebo VMware, kteří nabízejí oddělení na úrovni hardwaru. Poskytovatelé jako DigitalOcean, Kamatera nebo AWS nabízejí VPS založené na KVM s vyhrazenými zdroji. Pro bare-metal se ujistěte, že je povolena virtualizace na úrovni BIOS pro vnořené kontejnery. Poskytovatel, který izoluje tenanty na úrovni hypervizoru, doplňuje izolaci kontejnerů. Jak je podrobně popsáno v Zvládnutí izolace Dockeru pro bezpečný a efektivní web hosting, hostitelský OS by měl být také zpevněn s minimálním útočným povrchem.

Výhrady a kompromisy

Každá další vrstva přidává složitost a náklady na výkon. Uživatelské jmenné prostory mohou narušit svazky připojené k hostiteli. Profily Seccomp vyžadují ladění pro každou aplikaci. Sandboxované runtime jako gVisor nepodporují všechna syscally – vaše aplikace nemusí fungovat. Docker daemony pro jednotlivé tenanty zvyšují paměťovou režii. Zvolte úroveň izolace, která odpovídá vašemu hrozbovému modelu: pro důvěryhodné tenanty mohou stačit výchozí jmenné prostory; pro veřejný SaaS investujte do runtime sandboxů a politik Kubernetes. Před nasazením do produkce důkladně otestujte.

Závěr

Skutečná izolace více tenantů v Dockeru je dosažitelná vrstvením několika jaderných funkcí, runtime sandboxů a orchestrovaných kontrol. Začněte s uživatelskými jmennými prostory a seccomp, poté přejděte k daemonům pro jednotlivé tenanty nebo sandboxovaným runtime. Pro velká měřítka poskytuje Kubernetes politicky řízenou izolaci. Vždy kombinujte s oddělením na úrovni hypervizoru od renomovaného poskytovatele. Žádná technika není sama o sobě neprůstřelná, ale jejich kombinace vytváří robustní obranu. Vaši tenanté vám poděkují – a také váš bezpečnostní audit.