Daudzlietotāju Docker arhitektūras izstrāde: Pareizas izolācijas līmeņa izvēle

Kopsavilkums

Daudzlietotāju Docker mitināšanai nepieciešams līdzsvarot izmaksas, sarežģītību un izolāciju. Koplietojamie konteineri ir lēti, bet pastāv konteinera izbēgšanas risks; atsevišķi steks uz vienu nomnieku piedāvā spēcīgu izolāciju par augstākām izmaksām. Šis raksts apskata trīs biežākās arhitektūras: vienu Docker dēmonu ar namespaces, katra nomnieka Docker-in-Docker un atsevišķas virtuālās mašīnas uz vienu nomnieku. Jūs uzzināsiet, kā novērtēt nomnieku prasības, ieviest resursu ierobežojumus un izmantot tikai lasāmas failu sistēmas, lai nostiprinātu konteinerus. Mēs arī aplūkojam orķestrēšanas rīkus, piemēram, Kubernetes un Docker Swarm, lai pārvaldītu daudzlietotāju izvietošanu. Beigās jums būs lēmumu pieņemšanas ietvars, lai izvēlētos pareizo izolācijas līmeni jūsu lietošanas gadījumam. Piezīmes ietver veiktspējas pārslodzi un darbības sarežģītību. Secinājums uzsver, ka koplietojamā kodola izolācija ir pieņemama zema riska nomniekiem, bet spēcīga izolācija (bez koplietojama kodola) ir būtiska jutīgām darba slodzēm.

Kad jūs palaižat daudzlietotāju SaaS platformu uz Docker, lielākais arhitektūras lēmums ir tas, cik lielu izolāciju piemērot starp nomniekiem. Pārāk maza, un viens apdraudēts konteiners var izplest datus visā jūsu klientu bāzē. Pārāk liela, un jūs zaudējat izmaksu un darbības priekšrocības, ko konteineri solīja.

Šis raksts sniedz jums praktisku lēmumu ietvaru: novērtējiet savu nomnieku uzticības līmeņus, izvēlieties izolācijas arhitektūru, nostipriniet konteinerus un orķestrējiet mērogā. Jūs iegūsiet konkrētu kompromisu kopumu un soli pa solim plānu drošai izvietošanai.

1. solis: Novērtējiet nomnieku uzticību un jutīgumu

Ne visi nomnieki ir vienādi. Bezmaksas līmeņa lietotāji var būt apmierināti ar koplietojamu infrastruktūru, savukārt uzņēmumu klienti pieprasa spēcīgas garantijas. Klasificējiet nomniekus trīs līmeņos:

• Zema uzticība (piem., anonīmi izmēģinājuma lietotāji): minimāla izolācija ir pieņemama, augstākais ļaunprātīgas izmantošanas risks.
• Vidēja uzticība (piem., verificēti klienti): mērena izolācija nepieciešama, lai novērstu nejaušu traucējumu.
• Augsta uzticība (piem., parakstīti līgumi ar SLA): nepieciešama spēcīga izolācija – iespējams, atsevišķas virtuālās mašīnas.

Tāpat ņemiet vērā datu jutīgumu: ja nomnieki glabā PII vai finanšu datus, izvēlieties stingrāku izolāciju. Šī klasifikācija nosaka visus turpmākos lēmumus.

2. solis: Izvēlieties savu izolācijas arhitektūru

Iespēja A: Koplietojams Docker dēmons ar Linux namespaces (lētākais, vājākā izolācija)

Visi nomnieki darbojas kā konteineri uz viena resursdatora un viena Docker dēmona. Izolācija pilnībā balstās uz kodola namespaces un cgroups. Tas ir noklusējuma Docker modelis.

Plus: Zemākā pārslodze, viegli pārvaldāms, nav nepieciešami papildu rīki. Lieliski piemērots iekšējiem rīkiem vai nekritiskai daudzlietotāju videi.

Mīnusi: Kodola ievainojamība var sabojāt izolāciju. Ļaunprātīgs nomnieks var mēģināt veikt konteinera izbēgšanu. Resursu konkurence ir reāla – viens trokšņains kaimiņš var nomākt citus.

Kad izmantot: Zemas uzticības nomnieki ar pārejošiem datiem, piem., demonstrāciju vides vai CI/CD izpildītāji.

Iespēja B: Katra nomnieka Docker-in-Docker (vidēja izolācija, mērenas izmaksas)

Katrs nomnieks saņem savu Docker dēmonu konteinera iekšpusē (Docker-in-Docker – DinD). Tas nodrošina atsevišķu konteinera dzīves ciklu un neļauj vienam nomniekam redzēt cita konteinerus.

Plus: Labāka izolācija nekā koplietojamam dēmonam; katrs nomnieks var palaist savu Docker Compose steks. Noderīgi, ja nomniekiem pašiem jāveido un jāpārvalda savi konteineri.

Mīnusi: DinD ir zināmas problēmas – ligzdoti krātuves draiveri var radīt grūtības, un jūs joprojām koplietojat resursdatora kodolu. Veiktspējas pārslodze var būt 10-20% ligzdoto slāņu dēļ. Drošība nav perfekta; konteinera izbēgšana no DinD konteinera joprojām ved uz resursdatoru.

Kad izmantot: Vidējas uzticības nomnieki, kuriem nepieciešams sastādīt savus pakalpojumus, piem., platforma, kas ļauj lietotājiem izvietot pielāgotas tīmekļa lietotnes.

Iespēja C: Atsevišķas virtuālās mašīnas uz vienu nomnieku (spēcīgākā izolācija, augstākās izmaksas)

Katrs nomnieks darbojas uz atsevišķas virtuālās mašīnas ar Docker šajā VM. Hipervizors nodrošina aparatūras līmeņa izolāciju – nekādas kodola koplietošanas.

Plus: Spēcīgākā izolācija – konteinera izbēgšana sasniedz tikai VM, nevis citus nomniekus. Atbilst atbilstības prasībām, piemēram, PCI-DSS un HIPAA. Veiktspējas izolācija ir gandrīz absolūta.

Mīnusi: Augsta pārslodze (pilna OS uz vienu nomnieku), lēnāka nodrošināšana, lielāka pārvaldības sarežģītība. Jūs zaudējat konteineru blīvuma priekšrocības.

Kad izmantot: Augstas uzticības nomnieki ar jutīgiem datiem vai jebkurš nomnieks, kurā datu pārkāpums būtu katastrofāls.

3. solis: Nostipriniet konteinerus visās arhitektūrās

Neatkarīgi no izvēlētās arhitektūras, piemērojiet šīs drošības prakses vispārīgi:

• Izmantojiet uzticamus, minimālus bāzes attēlus (piem., Alpine, distroless), lai samazinātu uzbrukuma virsmu.
• Darbiniet konteinerus kā ne-root – nekad nedarbiniet kā root konteinera iekšienē. Iestatiet USER savā Docker failā.
• Iespējojiet tikai lasāmu saknes failu sistēmu konteinera specifikācijā; montējiet rakstāmus direktorijus tikai datiem.
• Iestatiet resursu ierobežojumus ar --memory, --cpus, lai novērstu trokšņaina kaimiņa problēmas.
• Ierobežojiet tīklošanu: izmantojiet lietotāja definētus tiltu tīklus un atsedziet tikai nepieciešamos portus.

Daudzlietotāju scenārijos ieviesiet arī:

• API ātruma ierobežošanu uz vienu nomnieku pie ieejas punkta.
• Revīzijas žurnālu visām konteineru darbībām.

Lai padziļināti izzinātu konteinera izbēgšanas novēršanu, skatiet mūsu ceļvedi: Aizsardzība pret konteinera izbēgšanu.

4. solis: Orķestrējiet daudzlietotāju izvietošanu

Manuāla daudzu konteineru pārvaldība ātri kļūst neapsaimniekojama. Izmantojiet orķestrētāju:

• Docker Swarm ir vienkāršākais: sākotnējā Docker integrācija, iebūvēta slodzes balansēšana un noslēpumu pārvaldība. Ideāli piemērots mazām un vidējām izvietošanām. Jūs varat novietot katra nomnieka steku uz atsevišķiem mezgliem, izmantojot etiķetes un ierobežojumus.
• Kubernetes piedāvā uzlabotāku izolāciju caur namespaces, NetworkPolicies un PodSecurityPolicies. Tomēr tas ievērojami palielina sarežģītību. Apsveriet pārvaldītu Kubernetes (GKE, EKS), lai samazinātu darbības slodzi.
• HashiCorp Nomad ir vieglāka alternatīva, kas atbalsta Docker un nekonteinera darba slodzes.

Lai iegūtu ražošanai gatavu orķestrēšanas iestatījumu, izlasiet Beyond Docker Compose: Orķestrējot ražošanai gatavas konteinerizētas lietotnes.

Piezīmes un kompromisi

• Veiktspējas pārslodze: DinD var palielināt CPU/atmiņas pārslodzi par 10-15%. VM pievieno 5-10% salīdzinājumā ar tukšo dzelzi, bet vairāk nekā konteineri. Testējiet reālistiskā slodzē.
• Darbības sarežģītība: Atsevišķas VM prasa pārvaldīt OS atjauninājumus, hipervizora ielāpus un VM dzīves ciklus. DinD rada problēmas ar krātuves draiveriem (overlay2 overlay2 iekšienē netiek atbalstīts; izmantojiet --storage-driver vfs, bet tas ir lēns).
• Atbilstība: Ja jums nepieciešams PCI-DSS, koplietojamā kodola arhitektūras parasti netiek pieņemtas. Izmantojiet VM ar pareizu segmentāciju.
• Izmaksas: Koplietojams Docker dēmons maksā gandrīz neko papildus. DinD maksā nedaudz vairāk CPU/atmiņas. VM var būt 2-5x dārgākas uz vienu nomnieku licencēšanas un resursu dēļ.

Secinājums: Jūsu lēmumu pieņemšanas ietvars

| Uzticības līmenis | Ieteicamā arhitektūra | Galvenās piezīmes | |-------------------|------------------------|-------------------| | Zema | Koplietojams Docker dēmons | Pieņemt konteinera izbēgšanas risku; ieviest ātruma ierobežošanu un revīziju. | | Vidēja | Katra nomnieka DinD | Risināt ligzdoto krātuvi; apsvērt drošības grupas katram nomniekam. | | Augsta | Atsevišķas VM ar Docker | Budžetā papildu skaitļošanai; automatizēt VM nodrošināšanu (piem., Terraform). |

Daudziem SaaS uzņēmumiem darbojas hibrīda pieeja: izmantot koplietojamu dēmonu bezmaksas līmeņiem, DinD maksājošiem klientiem un VM uzņēmumu klientiem. Tas sniedz izmaksu efektivitāti, kur risks ir zems, un spēcīgu izolāciju, kur tas ir svarīgi.

Atcerieties: izolācija ir spektrs, nevis bināra izvēle. Mērķis ir saskaņot aizsardzības līmeni ar datu vērtību un nomnieka uzticamību. Sāciet ar vienkāršāko variantu, kas atbilst jūsu drošības prasībām, pēc tam attīstiet pēc nepieciešamības.

Papildu labāko praksi konteineru konfigurāciju nostiprināšanai skatiet: Savu tīmekļa lietotņu drošība ar Docker: Praktisks ceļvedis izolācijai un labākajai praksei.