Žingsnis po žingsnio: kelių nuomininkų „Docker“ izoliavimo planas

Santrauka

Bendros infrastruktūros valdymas kelioms klientų kampanijoms ar vidiniams žiniatinklio projektams dažnai sukelia trintį su vadovybe dėl prieglobos išlaidų ir duomenų saugumo. „Docker“ konteineriai yra lengva alternatyva dedikuotoms virtualiosioms mašinoms, tačiau numatytosios sąrankos palieka rimtų izoliacijos spragų. Tikram kelių nuomininkų (angl. multi-tenancy) palaikymui reikalingos apgalvotos ribos branduolio, procesų, tinklo ir saugyklos lygmenyse. Šiame vadove pateikiamas praktinis penkių žingsnių planas, kaip apsaugoti kelių nuomininkų „Docker“ diegimus naudojant vietinius „Linux“ izoliavimo primityvus. Sužinosite, kaip taikyti išteklių kvotas, apriboti procesų teises, segmentuoti konteinerių tinklus ir pasirinkti tinkamą izoliacijos lygį. Vadovaudamiesi šiuo planu, galėsite apsaugoti nuomininkų aplinkas ir pagrįsti infrastruktūros biudžetus netechniniams vadovams.

Jūsų netechninis vadovas užeina pas jus su praėjusio mėnesio debesijos prieglobos sąskaitos išklotine. Išlaidos išaugo, tačiau keli itin svarbūs nukreipimo puslapiai patyrė vėlavimo šuolių vienu metu vykusio produkto paleidimo metu. Jūsų prašoma paaiškinti, kodėl rinkodaros ištekliai dalijasi serveriais, ar klientų duomenys yra saugūs ir kodėl komanda negali paleisti brangios dedikuotos virtualiosios mašinos kiekvienai atskirai kampanijai.

Suteikus kiekvienam skaitmeniniam projektui atskirą virtualiąją mašiną (VM), išvengiama „triukšmingų kaimynų“ problemos, tačiau tai greitai išeikvoja jūsų veiklos biudžetą. Standartiniai „Docker“ diegimai išsprendžia sąnaudų problemą paleidžiant kelias svetaines viename operacinės sistemos branduolyje, tačiau numatytosios konfigūracijos palieka pavojingų izoliacijos spragų. Jei vieno nuomininko programoje paleidžiamas nekontroliuojamas scenarijus arba įvyksta saugumo pažeidimas, kyla pavojus visoms tame pačiame serveryje esančioms programoms.

Pasinaudokite šiuo nuosekliu techniniu planu, kad sukonfigūruotumėte griežtą kelių nuomininkų izoliaciją „Docker“ aplinkoje. Įgyvendinkite šiuos penkis veiksmus, kad apsaugotumėte sistemos stabilumą, izoliuotumėte nuomininkų duomenis ir paverstumėte techninės infrastruktūros sprendimus aiškia verslo verte savo vadovybei.

---

1. Nustatykite griežtas išteklių kvotas naudodami „Control Groups“ (cgroups)

Nedelsdami nustatykite aiškius procesoriaus (CPU), atminties ir disko I/O apribojimus kiekvienam konteineriui. Kai keli nuomininkai dalijasi tuo pačiu serveriu, neapriboti konteineriai konkuruoja dėl sistemos išteklių. Viena nekontroliuojama duomenų bazės užklausa ar didelio lankomumo kampanija gali išnaudoti visą serverio atmintį, o tai privers „Linux“ „Out-Of-Memory“ (OOM) procesų naikiklį nutraukti atsitiktinius sistemos procesus.

„Linux“ valdymo grupės (cgroups) nustato, kiek skaičiavimo pajėgumų gali sunaudoti bet kuris konteineris. Pritaikykite šias ribas tiesiogiai savo diegimo aprašuose:

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

• Atminties ribos (limits.memory): nustato griežtą viršutinę ribą. Jei konteineris viršija 512 megabaitų, branduolys nutraukia procesus tame konteineryje nepakenkdamas kaimyniniams nuomininkams.
• Atminties rezervavimas (reservations.memory): garantuoja bazinį atminties paskirstymą, kad mažo lankomumo programos išliktų operatyvios.
• CPU ribos (limits.cpus): apriboja konteinerį iki maksimalios galimų CPU branduolių dalies, užkertant kelią situacijai, kai vienas nuomininkas pasisavina visus procesoriaus resursus.

Pagrįsdami šią architektūrą netechniniams vadovams, paaiškinkite cgroups kaip automatinius skaitmeninius skaitiklius. Lygiai taip pat, kaip biurų pastato nuomininkai moka už savo individualų elektros suvartojimą, o ne perkrauna pagrindinį saugiklį, cgroups užtikrina, kad vienas didelio srauto nukreipimo puslapis niekada nesutrikdys kito kliento potencialių pirkėjų generavimo portalo veiklos. Norėdami išsamiau susipažinti su architektūriniais kompromisais, skaitykite mūsų vadovą apie kelių nuomininkų architektūros projektavimą.

---

2. Segmentuokite nuomininkų procesus naudodami vardų sritis (Namespaces) ir ne „root“ vartotojus

Niekada nepaleiskite konteinerio procesų kaip numatytojo root vartotojo. Standartinėse „Linux“ konteinerių aplinkose „root“ vartotojas konteinerio viduje atitinka „root“ pagrindiniame serverio branduolyje, nebent jis yra aiškiai peradresuotas. Jei užpuolikas pažeidžia žiniatinklio programą, veikiančią „root“ teisėmis, jis įgyja išplėstines teises visame bendrame serveryje.

Užtikrinkite procesų izoliaciją per vartotojų vardų sritis (user namespaces) ir aiškų ne „root“ vykdymą:

1. Apibrėžkite neprivilegijuotus vykdymo laiko vartotojus: sukurkite specialius, žemų teisių paslaugų vartotojus savo „Dockerfile“ failuose.

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

2. Įgalinkite vartotojų vardų sritis (userns-remap): sukonfigūruokite „Docker“ demoną (/etc/docker/daemon.json), kad peradresuotumėte konteinerio vartotojų ID į neprivilegijuotą diapazoną pagrindiniame serveryje.

   {
     "userns-remap": "default"
   }
   

„Linux“ vardų sritys skaido sistemos matomumą. Proceso ID (PID) vardų sritis užtikrina, kad Nuomininkas A negalėtų matyti, siųsti signalų ar nutraukti Nuomininko B procesų. Prijungimo (MNT) vardų sritis suteikia kiekvienam nuomininkui izoliuotą failų sistemos vaizdą, o IPC vardų sritys blokuoja neteisėtą tarpprocesinį ryšį.

Vartotojų vardų sričių peradresavimas neutralizuoja išsiveržimo iš konteinerio (angl. container escape) grėsmes: procesas, kuris mano esąs root (UID 0) savo konteineryje, pagrindinėje mašinoje yra susietas su neprivilegijuotu ID (pavyzdžiui, UID 165536). Jei ataka apeina konteinerio barjerus, užpuolikas patenka į neprivilegijuotą aplinką, negalėdamas keisti pagrindinio serverio konfigūracijų ar pasiekti kaimyninių nuomininkų katalogų.

---

3. Pašalinkite branduolio privilegijas ir įgalinkite tik skaitomas failų sistemas

Apribokite pasiekiamas „Linux“ galimybes (capabilities) ir padarykite konteinerio šakninę failų sistemą nekintamą paleidimo metu. Numatytosios konteinerių vykdymo aplinkos suteikia maždaug tuziną „Linux“ branduolio teisių, kurių daugumos žiniatinklio programoms niekada neprireikia. Perteklinės teisės suteikia užpuolikams įrankius manipuliuoti tinklo maršrutizavimu, keisti serverio laikrodį arba apeiti prieigos prie failų kontrolę.

Apsaugokite veikiančius konteinerius atsisakydami visų numatytųjų teisių ir vėl pridėdami tik būtiniausias veiklos vėliavėles:

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: atima visas branduolio teises iš konteinerio proceso.
• cap_add: - NET_BIND_SERVICE: aiškiai leidžia prisijungti prie privilegijuotų prievadų (pvz., 80 ir 443), kartu blokuojant tiesiogines manipuliacijas tinklo lizdais (raw sockets).
• read_only: true: prijungia visą konteinerio šakninę failų sistemą tik skaitymo režimu. Užpuolikai negali atsisiųsti kenkėjiškų programų, keisti PHP scenarijų ar redaguoti žiniatinklio serverio konfigūracijos failų.
• tmpfs: priskiria laikinąsias, operatyviojoje atmintyje esančias direktorijas reikalingiems darbiniams failams (pvz., /tmp), kartu blokuodama vykdomųjų failų paleidimą (noexec) ir teisių eskalavimą (nosuid).

Taikykite saugaus skaičiavimo režimo („seccomp“) filtrus ir saugumo modulius, tokius kaip „AppArmor“ ar „SELinux“, kad perimtumėte ir apribotumėte sistemos iškvietimus į bendrą pagrindinio serverio branduolį. Jei jūsų komanda valdo individualias žiniatinklio programų komponavimo versijas, vadovaukitės mūsų struktūrizuotais žingsniais, skirtais „Docker“ konteinerių apsaugos stiprinimui visuose diegimo kanaluose.

---

4. Atskirkite tinklus tarp nuomininkų aplinkų

Išjunkite numatytąjį tinklo tiltą („bridge networking“) ir kiekvienam nuomininko rinkiniui sukurkite pritaikytus, izoliuotus programiškai apibrėžtus tinklo tiltus. Pagal numatytuosius nustatymus konteineriai, esantys standartiniame „Docker“ tilto tinkle, gali aptikti vieni kitus ir bendrauti per vidinius IP adresus. Vieno nuomininko rinkodaros mikropaslaugos pažeidžiamumas leidžia laisvai judėti į visas kitas tame serveryje esančias vidines duomenų bazes ir programas.

Visiškai izoliuokite nuomininkų srautą deklaruodami nepriklausomus tinklo tiltus kiekvienam nuomininkui:

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

• Nuomininkų izoliacija: alpha_app ir alpha_db bendrauja tik per tenant_alpha_net. beta_app negali pasiekti alpha_db, net jei užpuolikas skenuoja vidinį potinklį.
• Vidinė vėliavėlė (internal: true): neleidžia duomenų bazių tinklams nukreipti srauto tiesiai į išorinį internetą, apribojant įeinančią ir išeinančią prieigą tik prie programų konteinerių.
• Atvirkštinio tarpinio serverio (Reverse Proxy) šliuzas: tik įeinančio srauto tarpinis serveris jungiasi prie public_gateway_net, kad nukreiptų gaunamas HTTP/HTTPS užklausas į nurodytą nuomininko konteinerį pagal pagrindinio kompiuterio vardą (hostname).

Reiklesnėms aplinkoms apsvarstykite „Docker“ patobulintos konteinerių izoliacijos (ECI) režimus arba tokias vykdymo aplinkas kaip „Sysbox“, kurios automatiškai taiko griežtesnes vartotojų vardų sričių ribas ir virtualizuotas /proc bei /sys failų sistemas be sudėtingo rankinio tinklo konfigūravimo.

---

5. Nustatykite objektyvią kelių nuomininkų sprendimų matricą

Prieštaraukite prielaidai, kad visiems skaitmeniniams ištekliams reikalingos dedikuotos virtualiosios mašinos. Rinkodaros vadovai dažnai mano, kad aparatinio lygio VM izoliacija yra vienintelis patikimas saugumo modelis. Praktikoje dedikuotų VM diegimas paprastiems nukreipimo puslapiams ar trumpalaikėms kampanijų svetainėms sukelia didžiulį išlaidų augimą ir operacinės priežiūros naštą, nepagerindamas žiniatinklio programų saugumo.

Naudokite šią palyginimo matricą, kad įvertintumėte darbo krūvio reikalavimus ir pateiktumėte racionalių sprendimų strategiją vadovams:

Izoliacijos lygis	Pagrindinė technologija	Saugumo riba	Išteklių sąnaudos	Geriausias panaudojimo atvejis
Bendrojo rinkinio konteineriai	Vardų sritys ir Cgroups vienoje OS	Loginė OS lygio izoliacija	Labai mažos	Didelio lankomumo nukreipimo puslapiai, vidinė testavimo aplinka, laikinos kampanijų svetainės
Sustiprinti konteineriai (ECI / Sysbox)	Vartotojų vardų sritys, „AppArmor“, tik skaitoma šakninė sistema	Pažangi OS lygio izoliacija ir virtualizacija	Mažos	Kelių klientų agentūrų priegloba, autorizuoti portalai, jautrios rinkodaros formos
Dedikuotos virtualiosios mašinos (VM)	Hipervizoriaus aparatinė virtualizacija	Griežtas aparatinės įrangos / branduolio atskyrimas	Didelės	Mokėjimų apdorojimas, reglamentuojami HIPAA/PCI duomenys, nepatikimo individualaus kodo vykdymas
Hibridinis (konteineriai dedikuotose VM)	Sustiprinti konteineriai nuomininkui skirtose VM	Daugiasluoksnės aparatinės įrangos ir OS ribos	Nuo vidutinių iki didelių	Aukščiausio lygio verslo klientai, reikalaujantys dedikuoto sutartinio atitikimo

Įvertinkite kiekvieną projektą pagal griežtus kriterijus prieš skirdami infrastruktūros biudžetą:

1. Duomenų jautrumas: ar projekte saugomi reglamentuojami duomenys (pvz., kredito kortelių įrašai ar medicininė informacija)? Jei taip, diekite į dedikuotą VM.
2. Kodo kilmė: ar diegiate standartizuotą, komandos patikrintą kodą, ar leidžiate nepatikrintus trečiųjų šalių papildinius? Standartiniam kodui vieta sustiprintuose konteineriuose; nepatikrintam trečiųjų šalių kodui reikalinga hipervizoriaus izoliacija.
3. Biudžetas ir gyvavimo trukmė: sezoniniams nukreipimo puslapiams ir pagrindinėms įmonės svetainėms sustiprintas konteinerių kelių nuomininkų palaikymas užtikrina maksimalų našumą už kiekvieną investuotą eurą.

Pristatydami infrastruktūros planus vadovybei, pasinaudokite mūsų vadovu apie vertinimo, kada klientams reikia dedikuotų VM, kad pagrįstumėte savo rekomendacijas aiškiais lygiais pagrįstais argumentais.

---

Išvada: saugumo kontrolės pavertimas verslo investicijų grąža (ROI)

Kelių nuomininkų „Docker“ aplinkos apsaugai nereikia didžiulio įmonės lygio debesijos architektūros biudžeto. Tam reikia griežto ir disciplinuoto operacinės sistemos valdymo priemonių taikymo.

Peržiūrėdami infrastruktūrą su netechniniais vadovais, susiekite šias technines konfigūracijas su trimis vadovybei svarbiais rodikliais:

• Sąnaudų efektyvumas: kelių nuomininkų konteineriai leidžia komandai priglobti dešimtis rinkodaros svetainių sunaudojant tik dalį skaičiavimo išteklių, kurių reikalautų atskiros VM.
• Veikimo laiko (Uptime) apsauga: „Control groups“ garantuoja, kad sezoninės kampanijos srauto šuoliai nesumažins pagrindinių prekės ženklo svetainių našumo.
• Poveikio zonos ribojimas: tik skaitomos failų sistemos, pašalintos teisės ir izoliuoti tinklo tiltai užtikrina, kad vienos svetainės pažeidimas negalės pasiekti gretimų klientų duomenų bazių ar pagrindinio serverio valdymo elementų.

Sistemiškai įdiekite šiuos saugiklius savo konteinerių šablonuose. Taip sukursite našią, ekonomišką infrastruktūrą, atitinkančią tiek inžinerinius saugumo standartus, tiek vadovybės biudžeto apribojimus.