Kelių nuomininkų Docker architektūros kūrimas: tinkamo izoliavimo lygio pasirinkimas

Santrauka

Kelių nuomininkų Docker talpinimas reikalauja subalansuoti kainą, sudėtingumą ir izoliaciją. Bendri konteineriai yra pigūs, tačiau rizikuojama konteinerio pabėgimu; atskiri rinkiniai kiekvienam nuomininkui užtikrina stiprią izoliaciją, bet didesnėmis sąnaudomis. Šis straipsnis apžvelgia tris įprastas architektūras: vieną Docker demoną su vardų erdvėmis, kiekvieno nuomininko Docker-in-Docker ir atskiras VM kiekvienam nuomininkui. Sužinosite, kaip įvertinti savo nuomininkų reikalavimus, įgyvendinti išteklių ribojimus ir naudoti tik skaitymui skirtas failų sistemas konteineriams apsaugoti. Taip pat aptariame orkestravimo įrankius, tokius kaip Kubernetes ir Docker Swarm, skirtus valdyti kelių nuomininkų diegimus. Galiausiai turėsite sprendimų struktūrą, kad pasirinktumėte tinkamą izoliacijos lygį savo atvejui. Įspėjimai apima našumo papildomas sąnaudas ir operacinį sudėtingumą. Išvadoje pabrėžiama, kad bendra branduolio izoliacija yra priimtina mažos rizikos nuomininkams, tačiau stipri izoliacija (be bendro branduolio) yra būtina jautriems darbo krūviams.

Kai vykdote kelių nuomininkų SaaS platformą Docker, didžiausias architektūrinis sprendimas yra, kiek izoliacijos įgyvendinti tarp nuomininkų. Per mažai – ir vienas pažeistas konteineris gali nutekinti duomenis visoje klientų bazėje. Per daug – ir prarandate sąnaudas bei operacinius privalumus, kuriuos žadėjo konteineriai.

Šis straipsnis suteikia jums praktinę sprendimų struktūrą: įvertinkite savo nuomininkų pasitikėjimo lygius, pasirinkite izoliacijos architektūrą, apsaugokite konteinerius ir orkestruokite masteliu. Jūs gausite konkrečius kompromisus ir žingsnis po žingsnio planą saugiai diegti.

1 žingsnis: Įvertinkite nuomininkų pasitikėjimą ir jautrumą

Ne visi nuomininkai yra lygūs. Nemokamo plano vartotojams gali būti tinkama bendra infrastruktūra, o verslo klientai reikalauja stiprių garantijų. Suskirstykite nuomininkus į tris lygius:

• Žemas pasitikėjimas (pvz., anoniminiai bandomieji vartotojai): minimali izoliacija priimtina, didžiausia piktnaudžiavimo rizika.
• Vidutinis pasitikėjimas (pvz., patvirtinti klientai): vidutinė izoliacija reikalinga, kad būtų išvengta atsitiktinių trukdžių.
• Aukštas pasitikėjimas (pvz., pasirašytos sutartys su SLA): reikalinga stipri izoliacija – galbūt atskiros VM.

Taip pat apsvarstykite duomenų jautrumą: jei nuomininkai saugo asmens duomenis ar finansinę informaciją, rinkitės stipresnę izoliaciją. Ši klasifikacija lemia kiekvieną vėlesnį sprendimą.

2 žingsnis: Pasirinkite izoliacijos architektūrą

A variantas: Bendras Docker demonas su Linux vardų erdvėmis (Pigiausia, silpniausia izoliacija)

Visi nuomininkai veikia kaip konteineriai tame pačiame host ir tame pačiame Docker demono. Izoliacija visiškai priklauso nuo branduolio vardų erdvių ir cgroups. Tai yra numatytasis Docker modelis.

Privalumai: Mažiausios papildomos sąnaudos, lengva valdyti, nereikia papildomų įrankių. Puikiai tinka vidaus įrankiams ar ne kritinei kelių nuomininkų veiklai.

Trūkumai: Branduolio pažeidžiamumas gali sugriauti izoliaciją. Piktybinis nuomininkas gali bandyti pabėgti iš konteinerio. Išteklių konkurencija yra reali – vienas triukšmingas kaimynas gali išbadinti kitus.

Kada naudoti: Žemo pasitikėjimo nuomininkams su laikinais duomenimis, pvz., demonstracinėms aplinkoms arba CI/CD vykdymo programoms.

B variantas: Kiekvieno nuomininko Docker-in-Docker (Vidutinė izoliacija, vidutinės sąnaudos)

Kiekvienas nuomininkas gauna savo Docker demoną konteineryje (Docker-in-Docker – DinD). Tai užtikrina atskirą konteinerio gyvavimo ciklą ir neleidžia vienam nuomininkui matyti kito nuomininko konteinerių.

Privalumai: Geresnė izoliacija nei bendras demonas; kiekvienas nuomininkas gali paleisti savo Docker Compose rinkinį. Naudinga, kai nuomininkams reikia kurti ir valdyti savo konteinerius.

Trūkumai: DinD turi žinomų spąstų – įdėtieji saugyklos tvarkyklės gali sukelti problemų, ir jūs vis dar dalinatės host branduoliu. Našumo papildomos sąnaudos gali siekti 10-20% dėl įdėtų sluoksnių. Saugumas nėra tobulas; konteinerio pabėgimas iš DinD konteinerio vis tiek veda į host.

Kada naudoti: Vidutinio pasitikėjimo nuomininkams, kuriems reikia sudaryti savo paslaugas, pvz., platforma, leidžianti naudotojams diegti pasirinktines žiniatinklio programas.

C variantas: Atskiros VM kiekvienam nuomininkui (Stipriausia izoliacija, didžiausios sąnaudos)

Kiekvienas nuomininkas veikia dedikuotoje virtualioje mašinoje, o Docker yra toje VM. Hipervizorius suteikia aparatinės įrangos lygio izoliaciją – visiškai jokio branduolio bendrinimo.

Privalumai: Stipriausia izoliacija – konteinerio pabėgimas pasiekia tik VM, o ne kitus nuomininkus. Atitinka atitikties reikalavimus, tokius kaip PCI-DSS ir HIPAA. Našumo izoliacija yra beveik absoliuti.

Trūkumai: Didelės papildomos sąnaudos (visa OS kiekvienam nuomininkui), lėtesnis parengimas, daugiau valdymo sudėtingumo. Prarandate konteinerių tankio privalumą.

Kada naudoti: Aukšto pasitikėjimo nuomininkams su jautriais duomenimis, arba bet kuriam nuomininkui, kuriam pažeidimas būtų katastrofiškas.

3 žingsnis: Apsaugokite konteinerius visose architektūrose

Kad ir kurią architektūrą pasirinktumėte, šias saugumo praktikas taikykite visuotinai:

• Naudokite patikimus, minimalius bazinius vaizdus (pvz., Alpine, distroless) siekiant sumažinti atakos paviršių.
• Vykdykite konteinerius kaip ne root – niekada nevykdykite kaip root konteinerio viduje. Nustatykite USER savo Docker faile.
• Įgalinkite tik skaitymui skirtą root failų sistemą konteinerio specifikacijoje; duomenims montuokite tik rašomus katalogus.
• Nustatykite išteklių ribas su --memory, --cpus siekiant išvengti triukšmingo kaimyno problemų.
• Apribokite tinklą: naudokite vartotojo apibrėžtus tiltinius tinklus ir atidarykite tik būtinus prievadus.

Kelių nuomininkų scenarijuose taip pat įgyvendinkite:

• Kiekvieno nuomininko API užklausų ribojimą prieigos taške.
• Audito žurnalą visų konteinerio veiksmų.

Daugiau informacijos apie konteinerio pabėgimo prevenciją rasite mūsų vadove Apsauga nuo konteinerio pabėgimo.

4 žingsnis: Orkestruokite kelių nuomininkų diegimus

Rankinis daugelio konteinerių valdymas greitai tampa nevaldomas. Naudokite orkestratorių:

• Docker Swarm yra paprasčiausias: natūrali Docker integracija, įtaisytas apkrovos balansavimas ir paslapčių valdymas. Idealus mažiems ir vidutiniams diegimams. Galite kiekvieno nuomininko rinkinį išdėstyti dedikuotuose mazguose naudodami etiketes ir apribojimus.
• Kubernetes siūlo pažangesnę izoliaciją naudojant namespaces, NetworkPolicies ir PodSecurityPolicies. Tačiau tai prideda didelį sudėtingumą. Apsvarstykite valdomą Kubernetes (GKE, EKS), kad sumažintumėte operacinę naštą.
• HashiCorp Nomad yra lengvesnė alternatyva, palaikanti Docker ir ne konteinerinius darbo krūvius.

Norėdami gauti gamybai paruoštą orkestravimo sąranką, skaitykite Beyond Docker Compose: Gamybai paruoštų konteinerizuotų programų orkestravimas.

Įspėjimai ir kompromisai

• Našumo papildomos sąnaudos: DinD gali pridėti 10-15% CPU/atminties papildomų sąnaudų. VM prideda 5-10% lyginant su tiesiogine aparatūra, bet daugiau nei konteineriai. Išbandykite su realistine apkrova.
• Operacinis sudėtingumas: Atskiros VM reikalauja valdyti OS atnaujinimus, hipervizoriaus pataisas ir VM gyvavimo ciklus. DinD įveda problemų su saugyklos tvarkyklėmis (overlay2 viduje overlay2 nepalaikoma; naudokite --storage-driver vfs, bet tai lėta).
• Atitiktis: Jei jums reikia PCI-DSS, bendros branduolio architektūros paprastai nepriimamos. Naudokite VM su tinkamu segmentavimu.
• Kaina: Bendras Docker demonas beveik nieko nekainuoja. DinD kainuoja šiek tiek daugiau CPU/atminties. VM gali būti 2-5x brangesnės vienam nuomininkui dėl licencijavimo ir išteklių.

Išvada: Jūsų sprendimų struktūra

| Pasitikėjimo lygis | Rekomenduojama architektūra | Pagrindiniai įspėjimai | |-------------------|-----------------------------|------------------------| | Žemas | Bendras Docker demonas | Priimkite konteinerio pabėgimo riziką; įgyvendinkite užklausų ribojimą ir auditavimą. | | Vidutinis | Kiekvieno nuomininko DinD | Tvarkykite įdėtą saugyklą; apsvarstykite saugumo grupes kiekvienam nuomininkui. | | Aukštas | Atskiros VM su Docker | Skirkite biudžetą papildomiems skaičiavimams; automatizuokite VM parengimą (pvz., Terraform). |

Daugeliui SaaS įmonių tinka hibridinis metodas: naudokite bendrą demoną nemokamiems lygiams, DinD mokantiems klientams ir VM verslo klientams. Tai suteikia sąnaudų efektyvumą ten, kur rizika maža, ir stiprią izoliaciją ten, kur tai svarbu.

Atminkite: izoliacija yra spektras, o ne dvejetainis pasirinkimas. Tikslas yra suderinti apsaugos lygį su duomenų verte ir nuomininko patikimumu. Pradėkite nuo paprasčiausio varianto, atitinkančio jūsų saugumo reikalavimus, ir tobulinkite pagal poreikį.

Daugiau geriausių praktikų, kaip užrakinti konteinerių konfigūracijas, rasite Apsauga jūsų žiniatinklio programoms su Docker: Praktinis izoliacijos ir geriausių praktikų vadovas.