Millised kliendid tegelikult vajavad oma virtuaalmasinat? Astmeline Dockeri isolatsiooniplaan

Kokkuvõte

Agentuurid satuvad sageli paanikasse, kui klient küsib, kui hästi on nende andmed teistest rentnikest isoleeritud. Dockeri nimeruumid ja cgroupid annavad tõelise isolatsiooni, kuid need ei ole sama mis riistvaraline piir. Selle asemel, et käitada iga klient virtuaalmasinas – või hullem, kohelda kõiki kliente ühtemoodi – loo väike hulk isolatsioonitasemeid ja sobi iga klient nendega vastavalt andmete tundlikkusele, usaldusele ja nõuetele. Lukustatud konteiner (mitte-root, eemaldatud õigused, seccomp, kirjutuskaitstud juur) katab enamiku saitidest; reguleeritud või vaenulikud töökoormused saavad virtuaalmasina või konteineri virtuaalmasinas hübriidi. See postitus annab korratava otsustusvoogu, võrdlustabeli ja ausa pilgu sellele, millal rohkem isolatsiooni on ülepingutus.

Kas olete müügikõne punktis, kus uus klient ütleb: „me oleme tervishoid, näidake, et meie andmed on teie teistest klientidest isoleeritud“ ja te eelistaksite rääkida millestki muust?

See on agentuuri probleem: mitte üks täiuslik juurutamine, vaid sama usaldusväärse juurutamise kordamine tosina kliendi jaoks, kellel on erinevad eelarved, riskiprofiilid ja vastavusnõuded. Siin on aus versioon. Dockeri isolatsioon on tõeline, kuid see on spetsiifiline. Nimeruumid annavad igale konteinerile oma vaate protsessidele, võrgule ja failisüsteemile; cgroupid piiravad protsessorit, mälu ja ketta I/O-d, nii et rentnikud ei saa üksteist näljutada. See, mida see ei anna, on riistvaraline sein konteineri ja hostituuma vahel. Kui ründaja põgeneb konteinerist, on nad ainsa tuuma sees, mis teil on. Ülejäänud artikli muudab selle ebamugava fakti korratavaks otsuseks: klassifitseerige iga klient andmete tundlikkuse ja usalduse järgi, rakendage algtaseme tugevdamise profiili ja võtke virtuaalmasin kasutusele alles siis, kui rikkumise hind on kõrgem kui virtuaalmasina hind.

Oota, kas konteinerid pole juba isoleeritud?

Docker töötab Linuxi nimeruumide ja cgroupide peal ning need sõnad teevad tõelist tööd. Nimeruumid eraldavad protsessi ID-d, võrgupinu, mount-punktid ja kasutajad, nii et protsess ühes konteineris ei näe teise protsessitabelit. Cgroupid seavad piirid: anna konteinerile 0,5 protsessorit, 512 MB mälu ja fikseeritud ploki I/O kaal ning täpselt selle ta saab. Ühe rentniku kontrolli alt väljunud silmus aeglustatakse, mitte ei võta naabrit alla. Kui te pole piiranguid konfigureerinud, olete vahele jätnud kõige põhilisema asja, milleks cgroupid on mõeldud.

Võtke lihtne PHP rakendus konteineris A. See näeb oma failisüsteemi, oma võrguliidest, oma PID 1. Konteiner B näeb sama, kuid erineva vaatega. See on nimeruum. Nüüd kõndige minema ja jätke mälupiirang vahele: konteiner A saab täita hosti muutmälu ja panna konteiner B roomama. Selle vältimiseks ongi cgroupid olemas. Kuid kaks konteinerit saavad olla üksteisest isoleeritud nimeruumide kaudu ja jagavad siiski hostituuma, mis on osa, millest räägivad kõik konteineri põgenemise lood. Ärakasutus, mis jõuab tuumani, võib potentsiaalselt jõuda igale rentnikule sellel hostil.

„Docker on isoleeritud“ on pooltõde. Täpne versioon on: „Docker isoleerib nimeruumide ja cgroupidega ning tuuma haavatavus on plahvatuse raadius.“ Enne kui usaldate rentnikku käitama usaldamatut koodi, istuge selle mõttega hetkeks. Vastus ei ole „ära kunagi kasuta konteinereid“ – see on kerge paanika. Vastus on astmete süsteem.

Miks mõned kliendid vajavad rohkem kui nimeruume?

Aus vastus on, et isolatsioon ei ole lüliti, see on spekter. Ühes otsas on täielikult jagatud konteiner, kus kõik on tegelikult ühes rakenduses. Teises otsas on iga rentniku jaoks eraldi virtuaalmasin oma tuumaga. Enamik agentuuritööd asub ebamugavas keskel ja keskel ei ole binaarne valik „Docker on hea“ ja „käita kõigi jaoks virtuaalmasinat“.

Mis lükkab kliendi paremale, ei ole nende suurus. Need on neli küsimust:

• Kas nad hoiavad reguleeritud andmeid? Terviseandmed, maksekaardi andmed, kõik, mida regulaator nimetaks tundlikuks.
• Kas rikkumine nende rentnikus on realistlik tee teise rentnikuni? Kui nad saavad käitada suvalist koodi, siis jah.
• Kas usaldate koodi ja inimesi, kes seda juurutavad? Klient, kes palkab kõige odavama vabakutselise, ei ole sama usaldustase kui klient, kelle arendusmeeskonda te tunnete.
• Kas nende leping ütleb „pühendatud“, „isoleeritud“ või „privaatne“? Kui ütleb, siis olete juba lubanud astme; ainus ülesanne on nüüd õige valimine.

Kui te ei oska neile küsimustele veel vastata, pange klient algtaseme astmesse ja kirjutage eeldused üles. See ei ole turbekontroll; see on mõistuse kontroll, mida kordate iga kasutuselevõtu puhul.

Kuidas otsustan iga kliendi puhul ilma iga kord turvaauditit tegemata?

Tehke väike tabel ja pidage sellest kinni. Teil pole vaja neljakümne lahtriga maatriksit. Neli astet katavad peaaegu kõik kliendid, keda agentuur näeb.

Kliendi positsioon	Mis neid tegelikult eraldab	Millal kasutada
1. aste: Jagatud rakendus/konteiner	Ainult rakenduse loogika	Siseutiliidid, madala riskiga andmed, projektid, kus kõik on selgesõnaliselt ühes sisselogimissüsteemis
2. aste: Sama host, eraldi konteinerid	Nimeruumid ja cgroupid	Enamik turundussaitidest, kontaktvormid, tundlikke andmeid pole
3. aste: Lukustatud konteiner	2. aste + mitte-root, eemaldatud õigused, seccomp, kirjutuskaitstud juur, võrgu segmenteerimine	E-kaubandus, isikuandmed, kohandatud kood, mida te täielikult ei usalda
4. aste: Iga rentniku virtuaalmasin	Hüpervisor ja eraldi tuum	Tervishoid, rahandus, vastavusdokumendid, usaldamatu kood, mürarikkad naabrid

Siin on, kuidas see praktikas välja näeb. Pagariäri klient kontaktvormi ja Instagrami lingiga läheb 2. astmesse: üks konteiner jagatud hostil, vaikimisi Dockeri võrk, ressursipiirangud, töö tehtud. Veebipood, mis salvestab klientide nimesid, aadresse ja makse ümbersuunamisi, läheb 3. astmesse: sama jagatud host, kuid konteiner töötab mitte-root kasutajana, sellel puuduvad täiendavad tuumaõigused, kasutab seccomp-profiili ja avab ainult pordi 443. Meditsiiniline vastuvõtuportaal, mis salvestab kaitstud terviseteavet, läheb 4. astmesse: virtuaalmasin iga rentniku jaoks, sest rikkumise hind ei ole „me koristame ära“, vaid „me ei saa kliendile näidata, et võtsime neid tõsiselt“.

Kogu nipp on selles, et te ei mõtle iga kliendi jaoks arhitektuuri ümber. Te valite rea tabelist, milles juba kokku leppisite. Nii saab viieliikmeline agentuur käitada sada saiti ilma saja eraldi turvakinnisideeta. See tähendab ka, et järgmine klient ei saa vastust, mis sõltub sellest, milline meeskonnaliige telefoni vastu võttis. Nende valikute taga oleva sügavama arhitektuuriarutelu jaoks hõlmab see juhend mitme rentniku isolatsioonitasemete kujundamiseks üksikasjalikumalt kompromisse.

Kuidas näeb lukustatud konteiner tegelikult välja?

Lõpetame „lukustatud“ ütlemise ja muutume konkreetseks. See tähendab 3. astet tüüpilise WordPressi või PHP kliendi jaoks.

Esiteks vahetage kasutaja. Enamik ametlikke kujutisi töötab vaikimisi endiselt root'ina; teie Dockerfile'is looge mitte-root kasutaja ja käitage rakendust selle kasutajana. See eemaldab kohe kõige levinuma viisi, kuidas konteineri kompromiteerimine muutub hosti kompromiteerimiseks. Teiseks eemaldage õigused, mida te ei vaja. Käivitage --cap-drop ALL ja lisage tagasi ainult üks, tavaliselt NET_BIND_SERVICE, et rakendus saaks kuulata pordis 80. Juba see on suurem muudatus, kui enamik inimesi ootab. Kolmandaks muutke juurfailisüsteem kirjutuskaitstuks käsuga --read-only ja mountige kirjutatavad kataloogid (üleslaadimised, andmebaasi andmekataloog) köidetena või tmpfs-ina. Neljandaks rakendage seccomp-profiili ja kui teie host toetab, siis AppArmor või SELinux. Lõpuks pange konteiner spetsiaalsesse Dockeri võrku ja avage ainult pordid, mis peavad tegelikult kättesaadavad olema.

Vaatame läbi WordPressi näite. Aluskujutis töötab tõenäoliselt root'ina, seega lisate useradd sammu ja USER direktiivi. Käitate konteinerit mälupiirangu ja protsessoripiiranguga, nii et pluginapromet ei kahjusta naabrit. Mountite /var/www/html/wp-content/uploads kirjutatava köitena. Määrate --read-only. Ühendate selle võrku, mille läheduses pole ühtegi --privileged lippu. Tulemuseks on konteiner, mis oli varem „WordPressi sait“ ja on nüüd „WordPressi sait, mis juhtumisi on rohkem lukustatud kui enamik virtuaalseid privaatservereid“.

Kui kõige selle käsitsi tegemine tundub habras, on olemas lihtsam vahetee: Dockeri täiustatud konteineri isolatsioon, mis kasutab kasutaja nimeruumi isolatsiooni ja turvalist konteineri käitusaega. See on seaduslik otsetee, kuid mitte vabapääs mitte-root või õiguste eemaldamise vahelejätmiseks. Rentnik vajab ikka mõistlikku kujutist. Erinevus on selles, et kerneli poole jääv ründepind väheneb ilma, et te saaksite üleöö seccomp-eksperdiks. Kui soovite ühe rentniku jaoks täpset järjestust, muudab samm-sammult isolatsiooni tugevdamise juhend selle jaotise kopeeri-kleebi käskudeks.

Millal ma lõpetan kihtide lisamise ja annan neile lihtsalt virtuaalmasina?

Siin on vasturääkiv osa: rohkem isolatsiooni ei ole automaatselt parem. Virtuaalmasinad annavad riistvarataseme isolatsiooni, eraldi tuuma ja palju väiksema ründepinna, kui külalistuum langeb. Täpselt seda ootavad tervishoiu- ja rahanduskliendid, kui nad ütlevad „me tahame olla isoleeritud“. Kuid iga virtuaalmasin lisab paikamise, varundamise ja arvutusvõimsuse kulud ning korrutab laevastiku ajakohasena hoidmise tööd. Kui muudate iga kliendi virtuaalmasinaks, sest üks klient ütles kunagi, et Docker hirmutas teda, olete ostnud turvateatri päris raha eest.

Virtuaalmasin on õige vastus, kui risk rentniku kohta on suurem kui virtuaalmasina operatiivkulud rentniku kohta. See tähendab reguleeritud andmeid, kirjalikke vastavusnõudeid, usaldamatut kolmanda osapoole koodi või klienti, kes vajab mürarikka naabri eemaldamist. See on ka õige vastus, kui kliendi leping sõna otseses mõttes lubab pühendatud keskkonda, sest „konteiner“ ei ole see, mida nad allkirjastades „pühendatud“ all ette kujutavad.

Kuid virtuaalmasin ei vabanda lohakat konteinerit. Levinud lõks on panna klient virtuaalmasinasse ja jätta tugevdamine vahele, sest „virtuaalmasin kaitseb neid“. Virtuaalmasin kaitseb hosti rentniku eest, mitte rentnikku tema enda halva kujutise eest. Te ikka tahate mitte-root, eemaldatud õigused ja seccomp selles virtuaalmasinas. Hübriidmeetod – konteinerid virtuaalmasinas – on sageli kõige magusam koht: virtuaalmasin pakub piiri vastavusvestluste jaoks ja konteiner annab teile juurutamise töövoo, mida te juba tunnete. Selle arutelu pikem versioon on Kas iga rentnik peaks saama oma virtuaalmasina?, kuid lühike vastus on, et virtuaalmasin on lepingu jaoks, mitte hirmu jaoks.

Kuidas muudan selle korratavaks iga kliendi jaoks?

Teete selle korratavaks, muutes astmesüsteemi malliks, mitte mäluks. Hoidke kataloogi Compose-failidest, üks iga astme kohta: tier2-baseline, tier3-locked, tier4-vm-hybrid. Kui uus klient ilmub, kopeerige mall, muutke keskkonnamuutujaid ja te juba teate isolatsiooni kuju enne, kui olete kirjutanud rea uut infrastruktuuri.

Seejärel kirjutage otsus üles. Mitte 400-leheküljeline turbearuanne, vaid lühike lõik kliendi repositooriumis: milliseid andmeid nad säilitavad, millisel astmel nad on, miks ja mis viiks nad astme võrra kõrgemale. See lõik on väärt rohkem kui sada tulemüüri reeglit, sest see on asi, mida saate näidata järgmisele audiitorile või järgmisele murelikule kliendile. See hoiab teid ka meeldejätmisest, miks pagariäri sai 2. astme ja e-pood 3. astme, kui algne müügikõne on juba hääbunud.

Automatiseerige igavad kontrollid. Laske oma CI-l skannida iga kliendi kujutist ja ebaõnnestuda, kui see töötab root'ina, kui sellel on kõik õigused või kui see üritab avaldada porti, mida aste ei luba. Mitte miski sellest pole eksootiline; see on lihtsalt veendumine, et heatahtlik arendaja ei riku malli kogemata. Kui te ikkagi ehitate ümbritsevat hostimise töövoogu, hõlmab tootmisvalmis Dockeri hostimise strateegiate teos seda osa, mis tuleb pärast konteinerite määratlemist.

Miski selles pole särav. Ükski ajaveebipostitus ei muuda „rentniku isolatsiooni“ nii põnevaks kui rohelise välja arhitektuuriskeem. Kuid see on erinevus agentuuri vahel, mis vastab „kui isoleeritud me oleme?“ sõrmed ristis „täiesti“ ja sellise vahel, mis suudab näidata astet, konfiguratsiooni ja põhjust. Konteinerid ei ole maagiline sein. Virtuaalmasinad ei ole maagiline kuul. Astmesüsteem on lihtsalt otsus, mille kirjutate üles ja kasutate uuesti – ja agentuuri jaoks on korratavus kogu mäng.