Doseganje prave večnajemniške izolacije v Dockerju

Povzetek

Vsebniki Docker si delijo gostiteljsko jedro, kar je lahko varnostni pomislek za večnajemniška okolja, kjer si najemniki morda ne zaupajo. Ta članek pojasnjuje vrzeli v izolaciji v privzetih nastavitvah Docker in ponuja konkretne korake za krepitev izolacije z uporabo Linux imenskih prostorov, cgroups, uporabniških imenskih prostorov, seccomp, AppArmor in strojne virtualizacije. Naučili se boste, kako konfigurirati Docker demon po najemniku, uporabiti orodja za peskovnik kot gVisor ali Firecracker za močnejšo izolacijo ter orkestriranje s Kubernetes za večnajemništvo. Pokrili bomo tudi izbiro pravega ponudnika infrastrukture, ki ponuja KVM-based virtualizacijo za dodatno plast ločevanja. Na koncu boste imeli načrt za varno izvajanje večnajemniških obremenitev z Dockerjem.

Pri gostovanju več najemnikov na enem gostitelju Docker privzeta izolacija vsebnikov—zgrajena na Linux imenskih prostorih in cgroups—pogosto ni dovolj. Pobeg vsebnika pri enem najemniku bi lahko ogrozil celoten gostitelj in vse druge vsebnike. Ta težava je še posebej pereča v skupnem gostovanju, SaaS platformah ali katerem koli scenariju, kjer se nezaupanja vredna koda izvaja skupaj z vašo. Dobra novica: zlagate lahko več tehnik izolacije, da zgradite utrjeno večnajemniško okolje. Ta vodnik vas popelje skozi šest praktičnih korakov, od nizko visečih sadežev, kot so uporabniški imenski prostori, do naprednih ukrepov, kot so peskovniški runtime-i in izbire infrastrukture.

Razumevanje privzete izolacije Docker

Docker uporablja Linux imenske prostore za izolacijo procesov, omrežja, datotečnega sistema in drugih virov. Cgroups omejujejo CPU, pomnilnik in I/O. Vendar si ti delijo eno jedro—ranljivost v jedru lahko prizadene vse vsebnike. Za pravo večnajemništvo, zlasti z nezaupanja vrednimi najemniki, potrebujete obrambo v globino. Kot je obravnavano v Načrtovanje večnajemniške arhitekture Docker: Izbira prave ravni izolacije, se ravni izolacije gibljejo od šibke (samo imenski prostori) do močne (strojno virtualizirane). Gradimo od najšibkejše.

1. korak: Omogočite uporabniške imenske prostore

Privzeto se root znotraj vsebnika preslika v root na gostitelju. Pobeg vsebnika omogoči popoln dostop do gostitelja. Uporabniški imenski prostori preslikajo root vsebnika v zunanjega ne-root uporabnika. Omogočite ga globalno z dockerd --userns-remap=default ali po vsebniku z --userns=host. Ta preprost korak odpravi številne napade z dvigovanjem privilegijev. Preizkusite svoje aplikacije: nekatere, ki zahtevajo privilegije na ravni gostitelja (npr. priklop datotečnih sistemov), lahko odpovejo. Za Drupal ali WordPress je običajno varno.

2. korak: Uporabite profile Seccomp in AppArmor

Seccomp omejuje sistemske klice, ki jih vsebnik lahko izvede. Docker prinaša privzeti profil seccomp, ki blokira nevarne sistemske klice, kot sta mount in reboot. Za večnajemništvo ga dodatno zategnite—blokirajte redke sistemske klice, ki jih uporabljajo orodja za pobeg. Podobno lahko AppArmor omeji procese vsebnika. Ustvarite lasten profil AppArmor, ki zavrne pisanje v vmesnike jedra in omeji poti datotek. Oba se nastavita prek zastavic --security-opt. Kombinirajte ju za večplastno obrambo.

3. korak: Uporabite Docker demon po najemniku

Vodenje enega samega Docker demona za vse najemnike je tvegano—pobeg vsebnika bi lahko dostopal do vtičnice demona. Izolirajte demone po najemniku z uporabo Docker-in-Docker (DinD) ali oddaljenih končnih točk demona. Na primer, zaženite Docker demon znotraj vsebnika z --privileged (vendar to oslabi izolacijo). Boljši pristop: zaženite ločene demone na ločenih VM-jih ali uporabite Dockerjevo eksperimentalno funkcijo --group z uporabniškimi imenskimi prostori. Za orkestracijo je izolacija na podlagi Kubernetes imenskih prostorov bolj praktična, kot je obravnavano v Obramba pred pobegom iz vsebnika: Praktični vodnik za izolacijo Dockerja za večnajemniško gostovanje.

4. korak: Razmislite o peskovniških runtime-ih

Ko je samo Linux jedro nezaupano, uporabite peskovniški runtime, ki doda lahek VM sloj. gVisor (runsc) prestreže sistemske klice in izvaja lastno jedro, medtem ko Firecracker uporablja mikro-VM-je s strojno virtualizacijo. Oba se integrirata z Dockerjem prek containerd runtime-ov. Na primer, dodajte "runtimes": {"runsc": {}} v konfiguracijo Docker demona in zaženite vsebnike z --runtime=runsc. Prekoračitev zmogljivosti je 5–15 %, vendar je izolacija bistveno močnejša. Idealno za visoko varnostne večnajemniške nastavitve.

5. korak: Orkestrirajte s Kubernetes in varnostnimi politikami

Kubernetes ponuja domače večnajemništvo prek imenskih prostorov, standardov varnosti podov in omrežnih politik. Določite imenske prostore po najemniku s kvotami virov in uveljavite omejene varnostne kontekste podov (opustite vse zmogljivosti, samo bralni korenski datotečni sistem). Kontrolniki za sprejem, kot sta OPA/Gatekeeper, lahko blokirajo napačne konfiguracije. Če upravljate veliko najemnikov, Kubernetes avtomatizira uveljavljanje izolacije. Za orkestracijo v produkcijskem obsegu glejte Onkraj Docker Compose: Orkestriranje produkcijsko pripravljenih vsebniških aplikacij.

6. korak: Izberite pravega ponudnika gostovanja

Hipervizor vašega ponudnika infrastrukture je pomemben. Docker na skupnem gostovanju (OpenVZ) daje šibko izolacijo—en najemnik lahko vidi procese drugih. Raje izberite ponudnike, ki uporabljajo KVM ali VMware, ki ponujajo ločevanje na ravni strojne opreme. Ponudniki, kot so DigitalOcean, Kamatera ali AWS, ponujajo KVM-based VPS z namenskimi viri. Za bare-metal zagotovite, da je virtualizacija na ravni BIOS-a omogočena za ugnezdene vsebnike. Ponudnik, ki izolira najemnike na ravni hipervizorja, dopolnjuje vašo izolacijo vsebnikov. Kot je podrobno opisano v Obvladovanje izolacije Dockerja za varno in učinkovito spletno gostovanje, je treba tudi gostiteljski OS utrditi z minimalno napadalno površino.

Opozorila in kompromisi

Vsaka dodatna plast doda kompleksnost in stroške zmogljivosti. Uporabniški imenski prostori lahko pokvarijo nosilce, priklopljene na gostitelja. Profili seccomp zahtevajo prilagoditev za vsako aplikacijo. Peskovniški runtime-i, kot je gVisor, ne podpirajo vseh sistemskih klicev—vaša aplikacija morda ne bo delovala. Docker demoni po najemniku povečajo pomnilniško preobrementitev. Izberite raven izolacije, ki ustreza vašemu modelu groženj: za zaupane najemnike lahko zadoščajo privzeti imenski prostori; za javni SaaS vložite v runtime peskovnike in Kubernetes politike. Temeljito preizkusite pred produkcijo.

Zaključek

Pravo večnajemniško izolacijo v Dockerju je mogoče doseči z zlaganjem več jedrnih funkcij, runtime peskovnikov in orkestracijskih kontrol. Začnite z uporabniškimi imenskimi prostori in seccomp, nato napredujte do demonov po najemniku ali peskovniških runtime-ov. Za velik obseg Kubernetes ponuja politično vodeno izolacijo. Vedno kombinirajte s hipervizorsko ločenim gostiteljem pri uglednem ponudniku. Nobena posamezna tehnika ni neprebojna, vendar kombinacija ustvari robustno obrambo. Vaši najemniki vam bodo hvaležni—kot tudi vaš varnostni pregled.