Kas iga rentnik peaks saama oma VM?

Kokkuvõte

Mitme rentnikuga hostimine sunnib sind otsustama, kui kaugele saavad rentnikud üksteiseni ulatuda. Konteinerid kasutavad Linuxi nimeruume ja cgroups'e protsesside ja ressursside isoleerimiseks, kuid need jagavad hosti tuuma. Virtuaalmasinad lisavad riistvaratasandi piiri, kiiruse ja operatiivkoormuse arvelt. Hübriidne lähenemine — konteinerid VM-ide sees — võib anda mõlemad, kuid kahekordistab pinna, mida pead paikama. See artikkel juhendab sind riskipõhise otsuse, kõrvuti võrdluse ja Dockeri kõvendamistoimingute juurde, mis loevad isegi VM-i sees. Lõpuks tead, milline isolatsioonimudel sobib sinu rentnikele ja mida enne käivitamist konfigureerida.

Sinu mitme rentnikuga rakendus on peaaegu valmis. Sul on Docker Compose'i fail, mis käivitab iga kliendi jaoks stacki, ja see on kiire. Siis küsib sõber, kes haldab hostimisettevõtet: 'Kas annad igale rentnikule oma VM-i?' Sa tardud. Sa ei planeerinud seda küsimust. See artikkel annab sulle võimaluse täna vastata, ilma turvameeskonnata. Sa teed seda üksi, seega peab otsus olema piisavalt lihtne, et seda kaitsta kell 2 öösel.

Lõpeta parima mudeli otsimine. Alusta sellest, et kirjutad üles, mis juhtub, kui rentniku kood võtab sinu hosti üle. Defineeri plahvatusraadius enne, kui mõne tööriista valid. See harjutus ütleb sulle rohkem kui ükski benchmark.

Tuum on toakaaslane, keda sa ei saa välja tõsta

Konteinerid on tõhusad, sest nad jagavad hosti tuuma. See jagamine on kogu trikk ja kogu risk. Linuxi nimeruumid annavad igale konteinerile oma vaate protsessidest, võrgust ja failisüsteemist. Kontrollgrupid (cgroups) võimaldavad piirata CPU-d, mälu ja ketta I/O-d, et üks rentnik ei saaks teisi näljutada. Kuid kumbki ei loo riistvaraseina.

Mõtle konteinerist kui protsessist, millel on väga hea võlts ID. See usub, et on oma masinas. Tuum on aga üks Linuxi koopia, mis jookseb sinu hostis. Kui rentnik kasutab ära tuumanõrkuse, muutuvad nimeruumid metaandmeteks ja mitte millekski muuks. Ründaja, kes saab kutsuda tuumafunktsioone, jõuab teiste nimeruumideni samal tuumal. See on see konteineripõgenemine, millest sa pidevalt kuuled.

Oletame, et hostid väikest B2B-tööriista ühe konteineriga kliendi kohta. Klient installib kahtlase plugin'i koos kaugkoodi käivitamise veaga. Vaikimisi Dockeri seadetes töötab see protsess konteineri sees root'ina. Root konteineris on ikkagi UID 0 ja tuum ei erista seda UID-d hosti root'ist, kui sa kasutajaid sõnaselgelt ei kaardista. Ründaja võib üritada välja murda ja jagatud tuum on nende sihtmärk.

Tõrge ei pea olema dramaatiline. Üks rentnik, kes mälu lekitab, võib lükata hosti swappi, aeglustades kõiki teisi rentnikke. Ilma cgroup-piiranguteta on üks valesti käituv silmus kättesaadavusründeks. Nendega on see blokeeritud protsess ja hoiatus.

Kas see tähendab, et konteinerid on ebaturvalised? Ei. See tähendab, et pead käsitlema tuuma kui jagatud usaldustsooni. Enne valiku tegemist kirjuta ühelõiguline riskiavaldus: 'Kui rentniku konteiner on ohustatud, saab ründaja juurdepääsu: [loend]. Ettevõtte kulu oleks: [summa või mõju].' Kui see lõik hirmutab sind, pole sa paranoiline. Sa oled aus.

Põhjalikuma ülevaate saamiseks isolatsioonispektrist, alates jagatud konteineritest kuni täielikult eraldatud stackideni, vaata meie juhendit mitme rentnikuga Dockeri arhitektuuri kujundamise kohta.

Kolm viisi selle lõikamiseks (vali üks enne kasutuselevõttu)

Mitme rentniku isolatsiooni jaoks on tõesti kolm arhitektuuri. Iga 'parim tava' on nende kombinatsioon.

Lähenemine	Isolatsioonibarjäär	Parim, kui	Kõige raskem hoiatus
Rentnikupõhised konteinerid	Tuumaruumid + cgroups	Palju väikeseid rentnikke, väike risk rentniku kohta, vajadus tiheduse järele	Üks tuumaärakasutus võib murda kõik rentnikud sellel hostil
Üks VM rentniku kohta	Hüperviisor/riistvara virtualiseerimine	Reguleeritud andmed, vaenulikud rentnikud, kõrge väärtus rentniku kohta	Raskem, aeglasem ettevalmistus, paikad iga rentniku OS-i
Konteinerid VM-ide sees	VM piir konteineristatud töökoormuste ümber	Tihedus pluss kõva kest gruppide vahel	Kulud ja operatiivkoormus peaaegu kahekordistuvad

Rentnikupõhised konteinerid. See on enamiku SaaS-asutajate vaikimisi valik. Iga rentnik saab oma konteineri või väikese Compose stacki. Ettevalmistus on hetkeline, pildid on väikesed, CI/CD on lihtne. Ressursipiirangud hoiavad mürarikkaid naabreid serverit ära söömast. Kompromiss on jagatud tuum. Kui suudad hoida töökoormusi mitteprivilegeeritutena ja paikad hosti regulaarselt, on see sageli õige esimene samm.

Ära pane kahte rentnikku samasse konteinerisse. See on jagatud tuum pluss jagatud käitusaeg pluss jagatud failisüsteem. Kui üks rentnik laadib üles faili, mis loob protsessi, on teine rentnik juba samas protsessitabelis. Konteiner on sinu isolatsiooniüksus; tee sellest üks rentnik konteineri kohta.

Aga andmebaas? Kui iga rentnik ühendub samasse MongoDB või PostgreSQL'i eksemplari samade mandaatidega, oled juba lisanud suure jagatud komponendi. Anna igale rentnikule eraldi mandaadid ja ideaaljuhul eraldi andmebaas või skeem. Konteinerid isoleerivad rakenduse; andmebaas on sageli esimene leke, mida ründaja testib.

Üks VM rentniku kohta. Anna igale rentnikule täis virtuaalmasin. Hüperviisor lisab riistvaratasandi piiri, mis on täpselt see, mida tuumaärakasutus peab ületama, et hostini jõuda. See on oluline reguleeritud keskkondades või kui rentnikud on ebausaldusväärsed. Kulud on tihedus ja aeg. Nüüd haldad operatsioonisüsteemide laevastikku, mitte ainult konteinereid. Iga VM vajab uuendusi, turvaagente ja jälgimist. Üksi asutajale on see tõeline töö.

Mustrid, mis sellel tasandil töötavad: kasuta taristu-koodina (infrastructure-as-code), et luua VM samast baaspildist, küpseta uuendused uutesse piltidesse selle asemel, et paikata elavaid süsteeme, ja lõpeta töökoormused, mida sa ei tunne. Hoia VM-i haldusport suletuna internetile.

Konteinerid VM-ide sees. See hübriid saab algajate õpetustes harva käsitletud. Paned iga rentniku (või väikese rentnike grupi) ümber väikese VM-i ja käivitad seejärel konteinerid selle VM-i sees. VM on plahvatusraadiuse konteiner; konteinerid on lihtsalt käivitatavad üksused. See annab sulle virtualiseerimise kõva serva ja piltide reprodutseeritavuse. See maksab rohkem, sest maksad virtualiseerimise üldkulude ja konteinerite paindlikkuse eest, kuid see võib olla kõige mõistlikum pikaajaline mudel, kui sa ei saa rentnikke täielikult usaldada.

Üks levinud mikro-näide: rentnik käitab Node API-t ja taustatöötlejat. Selle asemel, et kasutada ühte suurt konteinerit mõlema protsessiga, kasuta ühte VM-i, seejärel kahte konteinerit erinevate ressurssipiirangutega, jagatud võrku ja ilma otsese interneti-ekspositsioonita töötlejale. VM annab kõva serva; konteinerid annavad struktuuri.

Millise peaksid valima? Tabel on sinu lühinimekiri. Järgmised lõigud muudavad otsuse käegakatsutavaks.

Kui valid konteinerid, tee need kuus asja või ära vaeva

Rentnikupõhised konteinerid on okei, kui kohtled iga konteinerit kui potentsiaalset ründajat. See algab konfiguratsioonist, mitte soovmõtlemisest.

0. Piira ressursse enne, kui kedagi usaldad. Cgroups'id on õiglusmehhanism ja kättesaadavuse kaitse. Sea iga konteineri jaoks --memory ja --cpus. Rentnik, kes mälu lekitab, peaks põrkama vastu oma piirangut, mitte sinu serveri oma. See ei ole turvapiir, kuid mürarikas naaber on rünnak ilma ühegi koodireata. Praktiline algus: --memory 512m --cpus 0.5. Töötleja protsessi jaoks alusta madalamalt ja skaleeri üles.

1. Käivita mitte-root kasutajana. Ära kunagi lase konteineri protsessil kasutada UID 0, kui sa seda hädasti ei vaja. Sea Dockerfile'is kasutaja ja lisa --user täiendava kaitsena. Privilegeerimata kasutajana töötav ärakasutus jõuab tuumani palju vähemate teedega. Selles Dockerfile'is loo kasutaja: RUN useradd -u 10001 app ja USER app. Ära jäta seda tegemata aja kokkuhoiuks.

2. Loobu igast võimekusest, mida sa ei vaja. Linuxi võimekused jagavad root'i võimu väikesteks tükkideks. Enamik veebirakendusi ei vaja peaaegu ühtegi. Alusta --cap-drop=ALL ja lisa tagasi ainult need, mida tead, et vajad. Konteiner ilma CAP_SYS_ADMIN-ita on nimeruumitrikkide jaoks palju raskem kasutada. Kui sinu rakendus üritab siduda privilegeeritud porti, käivita see kõrgel pordil ja pane ette puhverserver, selle asemel et anda NET_BIND_SERVICE.

3. Muuda failisüsteem kirjutuskaitstuks. Sinu rakendus ei tohiks kirjutada oma konteineri kihti. Mounti tmpfs oleku jaoks. Ründaja, kes ei saa kettale kirjutada, peab püsivuse istutamisega palju rohkem vaeva nägema. Ohustatud PHP-rakendus, mis üritab kirjutada veebikest, ebaõnnestub, kui juurfailisüsteem on kirjutuskaitstud. Sa võid mountida nimelise köite kirjutatava kataloogi jaoks, mida su rakendus tõesti vajab.

4. Rakenda seccomp ja AppArmor või SELinux. Need saadavad riskantsed süsteemikutsed prügikasti. Docker sisaldab vaikimisi seccomp-profiili; kasuta seda. Lisa veel ühe kihina AppArmor-profiil. Sa ei pea valdama iga süsteemikutset. Sa pead keelama selle, mida tavaline veebitöötleja kunagi ei vaja. Ära kunagi käivita --privileged lipuga. See lipp keelab peaaegu kõik kaitse, mille just seadistasid.

5. Segmenteeri võrk. Ära anna igale konteinerile teed igasse teise konteinerisse. Vaikimisi keela, seejärel ava ainult vajalikud pordid. Ohustatud andmebaasikonteiner ei tohiks skannida sinu halduspaneeli. Kui rentnikud on eraldi võrkudes, ei saa ühe võrgu rikkumine levida külgsuunas.

Praktiline algus:

docker run --user 10001 --cap-drop=ALL --security-opt no-new-privileges --read-only --tmpfs /tmp:rw,size=64M --security-opt seccomp=default.json --memory 512m --cpus 0.5 myimage

Pane samad lipud Compose-faili ja rakenda neid igale rentnikule. See pole täielik, kuid see on palju tugevam vaikimisi seadistus kui see, mida docker run sulle karbist välja annab.

Põhjalikuma läbikäigu jaoks kasuta meie samm-sammulist kõvendamise juhendit Dockeri konteineritele mitme rentnikuga hostimises.

Dockeri täiustatud konteineri isolatsioon on erand, millest peaksid teadma

Kui töötad hallatud Dockeri keskkonnas, otsi Dockeri täiustatud konteineri isolatsiooni (ECI). See kasutab kasutajanimeruumi isolatsiooni ja turvalist konteineri käitusaega kapoti all. Root konteineri sees kaardistub privilegeerimata kasutajaks hostis, nii et isegi konteiner, mis töötab root'ina, ei saa hosti root'i õigusi. See blokeerib ka vaikimisi ohtlikud võimekused ja süsteemikutsed. Seda ei saa tavalise Dockeri peal mõne lipuga taastada. Kui sinu platvorm toetab seda, lülita see sisse. See ei kaota vajadust mitte-root kasutajate ja ressurssipiirangute järele, kuid muudab riski matemaatikat.

Osa sellest saad ligikaudselt jäljendada kasutajanimeruumi ümberkaardistamisega (userns-remap) Dockeri daemonis. See pole nii täielik kui turvaline käitusaeg, kuid parem kui mitte midagi. Kui kasutad seda, kontrolli enne usaldamist, et UID-kaardistus töötab.

VM-eksitus: virtuaalmasinatele üleminek ei ole kõvendamine

Siin on vasturääkiv osa ja see on osa, mille enamik inimesi vahele jätab. Kui lähed üle ühele VM-ile rentniku kohta ja paigutad siis oma tavalised konteinerid selle sisse, pole sa oma konteineri turvaprobleemi eemaldanud. Oled lisanud laia puuri. Konteineripõgenemine töötab endiselt; ründaja maandub lihtsalt VM-i, mitte hosti. See on tõeline paranemine, kuid sul on endiselt vaja neid kuut sammu.

Teine lõks on eeldada, et VM ise on ohutu. Vaikimisi pilt nõrga SSH-parooliga, paikamata baaspaketid või avatud haldusport on kingitus. Hüperviisori piir loeb ainult siis, kui külaline on kõvendatud ja uuendatud. Vastasel juhul on sinu 'turvaline VM' kiirem tee kompromiteerimiseni, sest tunned end turvaliselt ja lõpetad kontrollimise.

Mida VM sulle annab, on vähendatav plahvatusraadius. Ühe rentniku katastroof jääb ühte VM-i. Mida see sulle maksab, on sinu aeg. Sinust saab nii paljude operatsioonisüsteemide süsteemiadministraator, kui sul on rentnikke. Kui oled üksi asutaja, kes toodet välja saadab, küsi, kas sul on tunde, et paikata ja jälgida laevastikku. Kui jah, võib VM rentniku kohta olla õige valik. Kui ei, siis võivad tugeva kõvendusega konteinerid olla ausamad.

Pea meeles ka, et sinu hüperviisori host on kriitiline sihtmärk. Ohustatud hüperviisor näeb kõiki külalisi. Paika hosti, mitte ainult külalisi. VM ei vabasta sind hosti paikamisest; see tõstab panuseid selle vahelejätmisel.

Hoiatus hübriidi kohta: ära eelda, et konteinerid VM-i sees annavad sulle 'kaks turvakihti' tasuta. VM lisab piiri; konteiner vajab endiselt mitte-root õigusi, võimekusi ja seccomp'i. Vastasel juhul on esimene kiht ainult nii tugev kui nõrgim konteiner.

Neli küsimust, mis lahendavad vaidluse kümne minutiga

Ära optimeeri abstraktselt. Esita endale need neli küsimust järjekorras. Kirjuta vastused üles.

1. Millele mu rentnikul on juurdepääs? Kui rentnik pääseb ainult oma veebirakendusele ja andmebaasile, on rentnikupõhised konteinerid rangete võrgureeglitega kaitstavad. Kui rentniku andmed on reguleeritud või rahaliselt tundlikud, liigu VM-ide poole.

2. Kui palju maksaks mulle ühe rentniku kompromiteerimine? Liida kokku kaotatud kliendid, õiguslik risk ja usaldus. Kui number on suurem kui VM-ide käitamise kulu, kuluta raha. Kui mitte, on konteinerid mõistlik valik.

3. Mitu rentnikku mul on ja kui palju nad maksavad? Palju väikeseid tellijaid: konteinerite tihedus on oluline. Käputäis suuri kontosid: anna igale VM ja esita arve vastavalt. Rentnikud, kes maksavad sulle vähem kui kohv, ei tohiks igaüks nõuda hallatavat OS-i.

4. Kas suudan asju ajakava järgi paikata? Konteinerid jagavad ühte hosti tuuma, nii et hosti paikamine kaitseb kõiki. VM-id korrutavad sinu paikamise sihtmärke. Kui tead, et jätad uuendused vahele, vali arhitektuur, millel on vähem liikuvaid osi ja raskemad vaikimisi seaded.

Sinu vastused rühmituvad. Kaks või enam VM-keskset vastust tähendab, et sa ei peaks vaikimisi rentnikupõhiseid konteinereid kasutama. Kolm või enam konteinerikeskset vastust tähendab, et VM-id on enneaegsed. Üks vastuintuitiivne tulemus: madala tuluga rentnik, kellel on juurdepääs tundlikele andmetele, vajab ikkagi VM-i, sest regulatiivne kulu pole seotud sellega, kui palju nad maksavad.

Saada välja kõige vähem, mida saad usaldada, seejärel teeni rohkem isolatsiooni

Sinu esimene arhitektuur ei pea olema sinu viimane. Alusta kõige rangema seadistusega, mida suudad tegelikult hooldada, ja lisa isolatsiooni, kui sinu rentnikubaas seda õigustab. Enamiku üksi tegutsejate jaoks tähendab see rentnikupõhiseid konteinereid mitte-root, piiratud võimekuste, kirjutuskaitstud failisüsteemide, seccomp'i ja võrgu segmentatsiooniga. Reguleeritud või kõrge väärtusega rentnike jaoks hüppa otse ühele VM-ile rentniku kohta, kus konteinerid on ainult pakenduskiht sees.

Ükskõik, mida valid, kirjuta otsus üles ja vaata see kord kvartalis uuesti läbi. Kui saad oma esimese küsimuse 'kas peaksime selle rentniku VM-i teisaldama?', on sul vastus ja sul on kontrollnimekiri, millele toetuda. See tähendabki isolatsioon tegelikult: kompromiss, mida haldad, mitte tehnoloogia, mida ostad.

Enne käivitamist vaata läbi meie praktiline Dockeri isolatsiooni turvakontrollinimekiri — see muudab need otsused loeteluks, mida saad kontrollida enne, kui näitad lehte kliendile.