Koji klijenti zaista trebaju sopstvenu VM? Slojeviti plan Docker izolacije

Sažetak

Agencije često paniče kada klijent pita koliko su njihovi podaci zaista izolovani od drugih zakupaca. Docker-ovi imenski prostori (namespaces) i cgroups pružaju stvarnu izolaciju, ali to nije isto što i hardverska granica. Umesto da svakog klijenta pokrenete na VM-u—ili još gore, tretirate svakog klijenta isto—napravite mali skup nivoa izolacije i uskladite svakog klijenta sa jednim prema osetljivosti podataka, poverenju i usklađenosti. Zaključani kontejner (non-root, bez mogućnosti, seccomp, root samo za čitanje) pokriva većinu sajtova; regulisana ili neprijateljska opterećenja dobijaju VM ili hibrid kontejner-u-VM. Ovaj post daje ponovljiv tok odlučivanja, tabelu poređenja i iskren pogled na to kada je veća izolacija preterivanje.

Jeste li u situaciji na prodajnom pozivu kada novi klijent kaže „mi smo u zdravstvu, pokažite nam da su naši podaci izolovani od vaših drugih klijenata” a vi biste radije pričali o bilo čemu drugom?

To je agencijski problem: ne savršeno jedno postavljenje, već isto pouzdano postavljenje ponovljeno kod desetak klijenata sa različitim budžetima, profilima rizika i zahtevima usklađenosti. Evo iskrene verzije. Docker izolacija je stvarna, ali je specifična. Imenski prostori daju svakom kontejneru sopstveni prikaz procesa, mreže i datotečnog sistema; cgroups ograničavaju CPU, memoriju i disk I/O tako da zakupci ne mogu da ugroze jedni druge. Ono što to ne kupuje jeste hardverski zid između kontejnera i jezgra domaćina. Ako napadač pobegne iz kontejnera, on je unutar jedinog jezgra koje imate. Ostatak ovog članka pretvara tu neprijatnu činjenicu u ponovljivu odluku: klasifikujte svakog klijenta prema osetljivosti podataka i poverenju, primenite osnovni profil očvršćavanja, i posegnite za VM-om samo kada je cena proboja veća od cene VM-a.

Čekaj, zar kontejneri već nisu izolovani?

Docker radi na Linux imenskim prostorima i cgroups, i te reči zaista rade posao. Imenski prostori razdvajaju ID-eve procesa, mrežne stekove, tačke montiranja i korisnike tako da proces u jednom kontejneru ne može videti tabelu procesa drugog. Cgroups postavljaju ograničenja: dajte kontejneru 0.5 CPU-a, 512 MB memorije i fiksnu težinu blok I/O-a, i to je tačno ono što dobija. Nezaustavljiva petlja kod jednog zakupca se ograničava umesto da obori suseda. Ako niste konfigurisali ograničenja, preskočili ste najosnovniju stvar za koju cgroups služe.

Uzmite jednostavnu PHP aplikaciju u kontejneru A. Ona vidi sopstveni datotečni sistem, sopstvenu mrežnu interfejs, sopstveni PID 1. Kontejner B ima isto, ali drugačiji prikaz. To su imenski prostori. Sada odstupite i preskočite memorijsko ograničenje: kontejner A može napuniti RAM domaćina i učiniti da kontejner B jedva radi. To je ono što cgroups treba da spreče. Ali dva kontejnera mogu biti izolovana jedan od drugog imenskim prostorima i i dalje deliti jezgro domaćina, što je deo o kome govori svaka priča o bekstvu iz kontejnera. Eksploatacija koja dosegne jezgro može potencijalno dosegnuti svakog zakupca na tom domaćinu.

„Docker je izolovan” je poluistinita rečenica. Tačna verzija je „Docker izoluje pomoću imenskih prostora i cgroups, a ranjivost jezgra je radijus eksplozije.” Pre nego što poverujete zakupcu da pokreće nepouzdani kod, zadržite se na toj misli minut. Odgovor nije „nikad ne koristiti kontejnere”—to je laka panika. Odgovor je sistem nivoa.

Pa zašto nekim klijentima treba više od imenskih prostora?

Iskren odgovor je da izolacija nije prekidač, već spektar. Na jednom kraju imate potpuno deljeni kontejner gde su svi efektivno u jednoj aplikaciji. Na drugom kraju imate zaseban VM po zakupcu sa sopstvenim jezgrom. Većina agencijskog posla živi u neudobnoj sredini, a sredina nije binarni izbor između „Docker je u redu” i „pokrenite VM za sve.”

Ono što gura klijenta udesno nije njihova veličina. To su četiri pitanja:

• Da li čuvaju regulisane podatke? Zdravstvene kartone, detalje platnih kartica, bilo šta što bi regulator nazvao osetljivim.
• Da li proboj na njihovom zakupcu ima realan put do drugog zakupca? Ako mogu da pokreću proizvoljni kod, da.
• Da li verujete kodu i ljudima koji ga postavljaju? Klijent koji angažuje najjeftinijeg frilensera nije isti nivo poverenja kao klijent čiji dev tim poznajete.
• Da li u njihovom ugovoru piše „namenski,” „izolovano,” ili „privatno”? Ako piše, već ste obećali nivo; sada je jedini posao izabrati pravi.

Ako još uvek ne možete odgovoriti na ta pitanja, stavite klijenta u osnovni nivo i zapišite pretpostavke. To nije bezbednosna revizija; to je provera zdravog razuma koju ponavljate pri svakom uključivanju klijenta.

Kako da odlučim po klijentu bez pokretanja bezbednosne revizije svaki put?

Napravite malu tabelu i posvetite joj se. Ne treba vam matrica sa četrdeset ćelija. Četiri nivoa će pokriti skoro svakog klijenta koga agencija vidi.

Pozicija klijenta	Šta ih zapravo razdvaja	Koristi kada
Nivo 1: Deljena aplikacija/kontejner	Samo logika aplikacije	Interne alatke, podaci niskog rizika, projekti gde su svi eksplicitno u jednom sistemu za prijavljivanje
Nivo 2: Isti domaćin, odvojeni kontejneri	Imenski prostori i cgroups	Većina marketing sajtova, kontakt forme, nema osetljivih podataka
Nivo 3: Zaključani kontejner	Nivo 2 + non-root, uklonjene mogućnosti, seccomp, root samo za čitanje, mrežna segmentacija	E-trgovina, PII, prilagođeni kod kome ne verujete u potpunosti
Nivo 4: VM po zakupcu	Hipervizor i zasebno jezgro	Zdravstvo, finansije, dokumentacija o usklađenosti, nepouzdani kod, bučni susedi

Evo kako to izgleda u praksi. Klijent pekara sa kontakt formom i Instagram vezom ide na Nivo 2: jedan kontejner na deljenom domaćinu, podrazumevano Docker mrežno povezivanje, ograničenja resursa, posao obavljen. Onlajn prodavnica koja čuva imena kupaca, adrese i preusmeravanja plaćanja ide na Nivo 3: isti deljeni domaćin, ali kontejner radi kao non-root korisnik, nema dodatnih mogućnosti jezgra, koristi seccomp profil i izlaže samo port 443. Medicinski portal za prijem koji čuva zaštićene zdravstvene informacije ide na Nivo 4: VM po zakupcu, jer cena proboja nije „počistićemo to” već „ne možemo klijentu pokazati da smo ih shvatili ozbiljno.”

Ceo trik je u tome što ne preispitujete arhitekturu za svakog klijenta. Birate red iz tabele oko koje ste se već dogovorili. Tako agencija od pet ljudi može voditi sto sajtova bez sto zasebnih bezbednosnih opsesija. To takođe znači da sledeći klijent ne dobija odgovor koji zavisi od toga koji je član tima podigao slušalicu. Za dublju arhitektonsku raspravu iza tih izbora, ovaj vodič o dizajniranju nivoa izolacije za više zakupaca detaljnije pokriva kompromise.

Kako zapravo izgleda zaključani kontejner?

Prestanimo da govorimo „zaključano” i budimo konkretni. To je ono što Nivo 3 znači za tipičnog WordPress ili PHP klijenta.

Prvo, promenite korisnika. Većina zvaničnih slika i dalje podrazumevano radi kao root; u vašem Dockerfile-u, kreirajte non-root korisnika i pokrenite aplikaciju kao taj korisnik. To odmah uklanja najčešći način na koji kompromitacija kontejnera postaje kompromitacija domaćina. Drugo, uklonite mogućnosti koje vam ne trebaju. Pokrenite sa --cap-drop ALL i vratite samo jednu, obično NET_BIND_SERVICE kako bi aplikacija mogla da sluša na portu 80. To je samo po sebi veća promena nego što većina ljudi očekuje. Treće, učinite root datotečni sistem samo za čitanje sa --read-only, i montirajte upisive direktorijume (otpremne datoteke, direktorijum baze podataka) kao volumene ili tmpfs. Četvrto, primenite seccomp profil i, ako vaš domaćin to podržava, AppArmor ili SELinux. Konačno, stavite kontejner na namensku Docker mrežu i izložite samo portove koji zaista moraju biti dostupni.

Prođimo kroz WordPress primer. Osnovna slika verovatno radi kao root, pa dodajete useradd korak i USER direktivu. Pokrećete kontejner sa memorijskim i CPU ograničenjem, tako da nalet saobraćaja od dodataka ne šteti susedu. Montirate /var/www/html/wp-content/uploads kao upisivi volumen. Postavite --read-only. Priključite ga na mrežu koja nema --privileged zastavicu nigde u blizini. Rezultat je kontejner koji je nekada bio „WordPress sajt” a sada je „WordPress sajt koji je slučajno više zaključan od većine virtuelnih privatnih servera.”

Ako vam se ručno nameštanje svega toga čini krhkim, postoji lakši srednji put: Docker-ova poboljšana izolacija kontejnera, koja koristi korisničku izolaciju imenskih prostora i sigurno okruženje za izvršavanje kontejnera. To je legitimna prečica, ali nije besplatna propusnica da preskočite non-root ili uklanjanje mogućnosti. Zakupac i dalje treba razumnu sliku. Razlika je u tome što se površina napada okrenuta jezgru smanjuje bez da preko noći postanete seccomp stručnjak. Ako želite tačan redosled za jednog zakupca, vodič za očvršćavanje izolacije korak po korak pretvara ovaj odeljak u komande za kopiranje i lepljenje.

Kada prestajem sa slojevima i jednostavno im dajem VM?

Evo kontrarnog dela: veća izolacija nije automatski bolja. VM-ovi vam daju izolaciju na nivou hardvera, zasebno jezgro i mnogo manju površinu napada ako padne gostujuće jezgro. To je tačno ono što klijenti iz zdravstva i finansija očekuju kada kažu „želimo da budemo izolovani.” Ali svaki VM dodaje trošak zakrpa, rezervnih kopija i računanja, i umnožava posao održavanja flote ažurnom. Ako svakog klijenta stavite na VM jer vam je jedan klijent jednom rekao da ga Docker plaši, kupili ste pozorište sigurnosti pravim novcem.

VM je pravi odgovor kada je rizik po zakupcu veći od operativnog troška VM-a po zakupcu. To znači regulisani podaci, pisani zahtevi usklađenosti, nepouzdani kod trećih strana, ili klijent kome treba ukloniti bučnog suseda. To je takođe pravi odgovor kada ugovor klijenta bukvalno obećava namensko okruženje, jer „kontejner” nije ono što zamišljaju kada potpišu „namenski.”

Ali VM ne opravdava aljkav kontejner. Česta zamka je staviti klijenta u VM i onda preskočiti očvršćavanje jer „VM ih štiti.” VM štiti domaćina od zakupca, ne zakupca od njegove sopstvene loše slike. I dalje želite non-root, uklonjene mogućnosti i seccomp unutar tog VM-a. Hibridni pristup—kontejneri unutar VM-a—često je idealna tačka: VM pruža granicu za razgovore o usklađenosti, a kontejner vam daje tok implementacije koji već znate. Duža verzija te rasprave je u Da li svaki zakupac treba da dobije sopstveni VM?, ali kratak odgovor je da je VM za ugovor, ne za strah.

Kako ovo činim ponovljivim kod svakog klijenta?

Činite to ponovljivim tako što sistem nivoa postaje šablon, a ne memorija. Držite direktorijum Compose datoteka, po jedan za svaki nivo: tier2-baseline, tier3-locked, tier4-vm-hybrid. Kada se pojavi novi klijent, kopirajte šablon, promenite promenljive okruženja i već znate oblik izolacije pre nego što napišete ijednu liniju nove infrastrukture.

Zatim zapišite odluku. Ne 400 stranica bezbednosnog izveštaja, već kratak pasus u repozitorijumu klijenta: koje podatke čuvaju, na kom su nivou, zašto i šta bi ih pomerilo na viši nivo. Taj pasus vredi više od sto firewall pravila, jer je to stvar koju možete pokazati sledećem revizoru ili sledećem zabrinutom klijentu. Takođe vas sprečava da morate pamtiti zašto je pekara dobila Nivo 2, a e-trgovina Nivo 3, nakon što je prvobitni prodajni poziv izbledeo.

Automatizujte dosadne provere. Neka vaš CI skenira svaku sliku klijenta i neka obori build ako radi kao root, ako ima sve mogućnosti, ili ako pokuša da objavi port koji nije među onima koje nivo dozvoljava. Ništa od toga nije egzotično; to je samo osiguravanje da šablon nije slučajno pokvaren od strane dobronamernog developera. Ako ionako gradite okolni hosting tok rada, članak o produkcijski spremnim Docker hosting strategijama pokriva deo koji dolazi nakon što su kontejneri definisani.

Ništa od ovoga nije glamurozno. Nijedan blog post neće učiniti da „izolacija zakupaca” zvuči uzbudljivo kao dijagram arhitekture na zelenoj površini. Ali to je razlika između agencije koja odgovara „koliko smo izolovani?” sa prekrštenim prstima „potpuno” i one koja može pokazati nivo, konfiguraciju i razlog. Kontejneri nisu magični zid. VM-ovi nisu magični metak. Sistem nivoa je samo odluka koju zapišete i ponovo koristite—a za agenciju, ponovljivost je cela igra.