Načrt po korakih za večnajemniško izolacijo v Dockerju

Povzetek

Upravljanje skupne infrastrukture za več naročniških kampanj ali internih spletnih mest pogosto povzroča trenja z vodstvom glede stroškov gostovanja in varnosti podatkov. Vsebniki Docker ponujajo lahko alternativo namenskim navideznim strežnikom (VM), vendar privzete nastavitve puščajo resne vrzeli v izolaciji. Prava večnajemniškost (multi-tenancy) zahteva premišljene meje na ravni jedra, procesov, omrežja in shrambe. Ta vodnik ponuja praktičen okvir v petih korakih za zavarovanje večnajemniških uvajanj Dockerja z uporabo izvornih primitivov za izolacijo v sistemu Linux. Naučili se boste uveljaviti kvote virov, omejiti privilegije procesov, segmentirati omrežja vsebnikov in izbrati pravo raven izolacije. Z upoštevanjem tega načrta lahko zaščitite okolja najemnikov in netehničnim deležnikom upravičite proračune za infrastrukturo.

Vaš netehnični vodja vstopi v vašo pisarno z izpisom računa za gostovanje v oblaku iz prejšnjega meseca. Stroški so narasli, več pristajalnih strani visoke prioritete pa je med hkratnim lansiranjem izdelka utrpelo skoke v zakasnitvi. Od vas zahtevajo pojasnilo, zakaj si trženjska sredstva delijo strežnike, ali so podatki strank izpostavljeni in zakaj ekipa ne more zagnati dragega namenskega navideznega strežnika za vsako posamezno kampanjo.

Dodelitev lastnega navideznega strežnika (VM) vsaki digitalni lastnini odpravlja težave s »hrupnimi sosedi« (noisy neighbors), vendar hitro izčrpa vaš operativni proračun. Standardne namestitve Dockerja rešujejo vprašanje stroškov z izvajanjem več spletnih mest na enem jedru operacijskega sistema, vendar privzete konfiguracije puščajo nevarne vrzeli v izolaciji. Če se v aplikaciji enega najemnika pojavi podivjan skript ali zlonameren vdor, so ogrožene vse sogostovane aplikacije na tem gostitelju.

Uporabite ta tehnični načrt po korakih za konfiguracijo stroge večnajemniške izolacije v Dockerju. Uvedite teh pet operativnih korakov, da zaščitite stabilnost sistema, izolirate podatke najemnikov in tehnične infrastrukturne odločitve pretvorite v jasno poslovno vrednost za vaše vodstvo.

---

1. Uveljavite stroge kvote virov z uporabo nadzornih skupin (cgroups)

Na vsakem vsebniku nemudoma nastavite izrecne omejitve za procesor, pomnilnik in V/I diska. Kadar si več najemnikov deli osnovnega gostitelja, neomejeni vsebniki tekmujejo za sistemske vire. Ena podivjana poizvedba v podatkovni bazi ali kampanja z visokim prometom lahko porabi celoten pomnilniški sklad gostitelja, kar sproži mehanizem Linux Out-Of-Memory (OOM) killer, ki samodejno zaustavi poljubne sistemske procese.

Nadzorne skupine v Linuxu (cgroups) upravljajo, koliko računske zmogljivosti lahko porabi kateri koli vsebnik. Te meje uveljavite neposredno v definicijah uvajanja:

services:
  tenant_app:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.75'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

• Omejitve pomnilnika (limits.memory): Določajo fiksno zgornjo mejo. Če vsebnik preseže 512 megabajtov, jedro zaustavi procese v tem vsebniku, ne da bi to poslabšalo delovanje sosednjih najemnikov.
• Rezervacije pomnilnika (reservations.memory): Zagotavljajo osnovno dodelitev pomnilnika, da aplikacije z nizkim prometom ostanejo odzivne.
• Omejitve procesorja (limits.cpus): Omejijo vsebnik na največji delež razpoložljivih procesorskih jeder, kar preprečuje pomanjkanje procesorskih virov zaradi enega samega najemnika.

Kadar to arhitekturo utemeljujete netehničnemu vodstvu, opišite cgroups kot avtomatizirane digitalne podštevce. Tako kot najemniki v poslovni stavbi plačujejo lastno porabo elektrike, namesto da bi preobremenili glavno varovalko, cgroups zagotavljajo, da ena pristajalna stran z visokim prometom nikoli ne sesuje portala za pridobivanje potencialnih strank drugega naročnika. Za podrobnejši pregled arhitekturnih kompromisov si oglejte naš vodnik o načrtovanju večnajemniške arhitekture.

---

2. Segmentirajte procese najemnikov z imenskimi prostori in neskrbniškimi uporabniki

Nikoli ne izvajajte procesov vsebnikov s privzetim korenskim uporabnikom (root). V standardnih okoljih vsebnikov Linux korenski uporabnik znotraj vsebnika ustreza uporabniku root na jedru osnovnega gostitelja, razen če je izrecno preslikan. Če napadalec vdre v spletno aplikacijo, ki se izvaja kot root, pridobi povišane privilegije nad celotnim skupnim gostiteljem.

Uveljavite izolacijo procesov prek uporabniških imenskih prostorov in izrecnega izvajanja brez korenskih pravic:

1. Določite neprivilegirane izvajalne uporabnike: V svojih datotekah Dockerfile ustvarite namenske storitvene uporabnike z nizkimi pravicami.

   FROM php:8.2-fpm-alpine
   RUN addgroup -g 10001 tenantgroup && \
       adduser -u 10001 -D -G tenantgroup tenantuser
   USER tenantuser
   

2. Omogočite uporabniške imenske prostore (userns-remap): Konfigurirajte demon Docker (/etc/docker/daemon.json), da preslika uporabniške ID-je vsebnikov v neprivilegiran obseg na gostitelju.

   {
     "userns-remap": "default"
   }
   

Imenski prostori Linuxa razdelijo sistemsko vidljivost. Imenski prostor ID-jev procesov (PID) zagotavlja, da Najemnik A ne more videti, pošiljati signalov ali zaustavljati procesov Najemnika B. Imenski prostor priklopov (MNT) vsakemu najemniku omogoča izoliran pogled na datotečni sistem, medtem ko imenski prostori IPC blokirajo nepooblaščeno medprocesno komunikacijo.

Preslikava uporabniških imenskih prostorov nevtralizira vektorje za pobeg iz vsebnika: proces, ki meni, da je root (UID 0) znotraj svojega vsebnika, je na gostiteljskem računalniku preslikan v neprivilegiran ID (kot je UID 165536). Če izkoriščanje zaobide pregrade vsebnika, napadalec pristane v neprivilegirani lupini, ki ne more spreminjati konfiguracij gostitelja ali dostopati do imenikov sosednjih najemnikov.

---

3. Odstranite zmožnosti jedra in uveljavite datotečne sisteme samo za branje

Odvzemite razpoložljive zmožnosti Linuxa (capabilities) in zagotovite nespremenljivost korenskega datotečnega sistema vsebnika ob zagonu. Privzeta izvajalna okolja vsebnikov podeljujejo približno ducat zmožnosti jedra Linuxa, med katerimi spletne aplikacije mnogih sploh ne potrebujejo. Presežne zmožnosti napadalcem omogočajo manipulacijo omrežnega usmerjanja, spreminjanje sistemskega časa ali obhod nadzora dostopa do datotek.

Zavarujte izvajalne vsebnike tako, da opustite vse privzete zmožnosti in dodate le bistvene operativne zastavice:

services:
  tenant_web:
    image: custom-nginx:latest
    read_only: true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    security_opt:
      - no-new-privileges:true
      - seccomp=default.json
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
      - /var/run:rw,noexec,nosuid,size=16m

• cap_drop: - ALL: Procesu vsebnika odvzame vsako zmožnost jedra.
• cap_add: - NET_BIND_SERVICE: Izrecno dovoljuje vezavo na priviligirana vrata (kot sta 80 in 443), medtem ko onemogoča neposredno manipulacijo z omrežnimi vtičniki (raw sockets).
• read_only: true: Priklopi celoten korenski datotečni sistem vsebnika kot samo za branje. Napadalci ne morejo prenašati zlonamernih binarnih datotek, spreminjati skriptov PHP ali urejati konfiguracijskih datotek spletnega strežnika.
• tmpfs: Dodeli začasne imenike v pomnilniku za nujne delovne datoteke (kot je /tmp), pri tem pa blokira izvajanje binarnih datotek (noexec) in povišanje privilegijev (nosuid).

Uporabite filtre varnega računalniškega načina (seccomp) in varnostne module, kot sta AppArmor ali SELinux, da prestrežete in omejite sistemske klice, poslane v skupno jedro gostitelja. Če vaša ekipa upravlja gradnje spletnih aplikacij po meri, sledite našim strukturiranim korakom za utrjevanje vsebnikov Docker v svojih cevovodih za uvajanje.

---

4. Razdelite omrežja med okolji najemnikov

Onemogočite privzeto premostitveno omrežje (bridge) in vzpostavite prilagojena, izolirana programsko določena omrežja za vsak sklad najemnika. Privzeto lahko vsebniki, nameščeni na standardnem premostitvenem omrežju Docker, odkrivajo drug drugega in komunicirajo prek internih naslovov IP. Ranljivost v trženjski mikrostoritvi enega najemnika omogoča lateralno premikanje do vseh drugih internih podatkovnih baz in aplikacij na tem gostitelju.

Promet najemnikov popolnoma izolirajte z uvedbo neodvisnih omrežnih mostov za vsakega najemnika:

networks:
  tenant_alpha_net:
    driver: bridge
    internal: true
  tenant_beta_net:
    driver: bridge
    internal: true
  public_gateway_net:
    driver: bridge

services:
  alpha_app:
    image: tenant_a_app:latest
    networks:
      - tenant_alpha_net
      - public_gateway_net

  alpha_db:
    image: mariadb:10.11
    networks:
      - tenant_alpha_net

  beta_app:
    image: tenant_b_app:latest
    networks:
      - tenant_beta_net
      - public_gateway_net

  beta_db:
    image: mariadb:10.11
    networks:
      - tenant_beta_net

• Izolacija najemnikov: alpha_app in alpha_db komunicirata izključno prek omrežja tenant_alpha_net. beta_app ne more doseči alpha_db, tudi če napadalec pregleda celotno interno podomrežje.
• Interna zastavica (internal: true): Preprečuje omrežjem podatkovnih baz neposredno usmerjanje prometa v zunanji internet, s čimer omeji dohodni in odhodni dostop izključno na aplikacijske vsebnike.
• Vhodni reverzni posrednik (Reverse Proxy Gateway): Samo vstopni posredniški strežnik se poveže z public_gateway_net, da usmerja dohodne zahteve HTTP/HTTPS do določenega vsebnika najemnika glede na ime gostitelja.

Za zahtevnejša okolja razmislite o Dockerjevih načinih Enhanced Container Isolation (ECI) ali izvajalnih okoljih, kot je Sysbox, ki samodejno uveljavljajo strožje meje uporabniških imenskih prostorov ter virtualizirana datotečna sistema /proc in /sys brez zapletenega ročnega konfiguriranja omrežja.

---

5. Vzpostavite objektivno matriko odločanja za večnajemništvo

Zavračajte predpostavko, da vsa digitalna sredstva zahtevajo namenske navidezne strežnike. Vodje trženja pogosto domnevajo, da je izolacija na ravni strojne opreme prek VM edini sprejemljiv varnostni model. V praksi dodeljevanje namenskih navideznih strežnikov za nezahtevne pristajalne strani ali kratkotrajna spletna mesta kampanj povzroča ogromno napihovanje stroškov in operativno breme vzdrževanja, ne da bi s tem dejansko izboljšali varnost spletnih aplikacij.

Uporabite naslednjo primerjalno matriko za oceno zahtev delovnih obremenitev in predstavitev racionalne strategije uvajanja odločevalcem:

Raven izolacije	Osnovna tehnologija	Varnostna meja	Obremenitev virov	Najboljši primer uporabe
Vsebniki v skupnem skladu	Imenski prostori in cgroups na enem OS	Logična izolacija na ravni OS	Zelo nizka	Pristajalne strani z visokim prometom, interna testna okolja, začasna spletna mesta kampanj
Utrjeni vsebniki (ECI / Sysbox)	Uporabniški imenski prostori, AppArmor, korenski datotečni sistem samo za branje	Napredna raven OS in virtualizacija	Nizka	Agencijsko gostovanje za več strank, overjeni portali, občutljivi trženjski obrazci
Namenski navidezni strežniki (VM)	Hardverska virtualizacija hipervizorja	Stroga ločitev strojne opreme/jedra	Visoka	Obdelava plačil, regulirani podatki HIPAA/PCI, izvajanje nezaupljive kode po meri
Hibrid (vsebniki v namenskih VM)	Utrjeni vsebniki znotraj namenskih VM najemnikov	Večplastne meje strojne opreme in OS	Zmerna do visoka	Zahtevne korporativne stranke, ki zahtevajo namensko pogodbeno skladnost

Pred dodelitvijo proračuna za infrastrukturo ovrednotite vsak projekt glede na stroga merila:

1. Občutljivost podatkov: Ali projekt shranjuje regulirane podatke (npr. podatke o kreditnih karticah ali zdravstvene kartoteke)? Če da, ga namestite na namenski navidezni strežnik.
2. Izvor kode: Ali uvajate standardizirano kodo, ki jo je pregledala vaša ekipa, ali dovoljujete nepreverjene vtičnike tretjih oseb? Standardna koda sodi v utrjene vsebnike; nepreizkušena koda tretjih oseb zahteva izolacijo na ravni hipervizorja.
3. Proračun in življenjska doba: Za sezonske pristajalne strani in osrednja spletna mesta podjetja večnajemništvo z utrjenimi vsebniki zagotavlja najboljše razmerje med zmogljivostjo in ceno.

Ko vodstvu predstavljate infrastrukturne načrte, si oglejte naš vodnik o ocenjevanju, kdaj stranke potrebujejo namenske navidezne strežnike, da svoja priporočila podprete z jasnimi argumenti po ravneh.

---

Zaključek: Pretvarjanje varnostnih kontrol v poslovni ROI

Zavarovanje večnajemniškega okolja Docker ne zahteva proračuna za oblačno arhitekturo velikih podjetij. Zahteva dosledno in disciplinirano uporabo kontrol operacijskega sistema.

Ko infrastrukturo pregledujete z netehničnim vodstvom, te tehnične konfiguracije predstavite skozi tri ključne poslovne metrike:

• Stroškovna učinkovitost: Večnajemniški vsebniki ekipi omogočajo gostovanje več deset trženjskih spletnih mest z delčkom računske zmogljivosti, ki bi jo zahtevali posamezni navidezni strežniki.
• Zaščita razpoložljivosti (uptime): Nadzorne skupine (cgroups) zagotavljajo, da skoki v prometu pri sezonski kampanji ne bodo poslabšali delovanja osrednjih spletnih mest blagovne znamke.
• Omejitev obsega škode (blast radius): Datotečni sistemi samo za branje, odvzem zmožnosti in izolirani omrežni mostovi zagotavljajo, da morebiten vdor na enem spletnem mestu ne more dostopati do sosednjih podatkovnih baz strank ali nadzora nad gostiteljem.

Te zaščitne mehanizme sistematično implementirajte v svoje predloge za vsebnike. Tako boste zagotovili visoko zmogljivo in stroškovno učinkovito infrastrukturo, ki izpolnjuje tako inženirske varnostne standarde kot proračunske zahteve vodstva.