Soli pa solim: plāns daudznomnieku Docker izolācijai

Kopsavilkums

Kopīgotas infrastruktūras pārvaldība vairāku klientu kampaņām vai iekšējiem tīmekļa resursiem bieži izraisa domstarpības ar vadību par uzturēšanas izmaksām un datu drošību. Docker konteineri piedāvā vieglu alternatīvu dedikētām virtuālajām mašīnām, taču noklusējuma konfigurācijas atstāj būtiskus izolācijas robus. Patiesai daudznomnieku (multi-tenancy) videi ir nepieciešamas pārdomātas robežas kodola, procesu, tīkla un krātuves līmenī. Šajā ceļvedī sniegta praktiska piecu soļu sistēma daudznomnieku Docker izvietojumu aizsardzībai, izmantojot Linux iebūvētos izolācijas mehānismus. Jūs uzzināsiet, kā ieviest resursu kvotas, ierobežot procesu privilēģijas, segmentēt konteineru tīklus un izvēlēties pareizo izolācijas līmeni. Sekojot šim plānam, varat pasargāt nomnieku vides un pamatot infrastruktūras budžetu vadībai bez tehniskām priekšzināšanām.

Jūsu vadītājs ienāk kabinetā ar pagājušā mēneša mākoņpakalpojumu rēķina izdruku. Izmaksas ir pieaugušas, tomēr vairākām prioritārām mērķlapām vienlaicīgas produktu palaišanas laikā radās aiztures lēcieni. Jums lūdz paskaidrot, kāpēc mārketinga resursi atrodas uz vieniem un tiem pašiem serveriem, vai klientu dati nav apdraudēti un kāpēc komanda nevar palaist dārgu atsevišķu virtuālo mašīnu katrai kampaņai.

Atsevišķas virtuālās mašīnas (VM) piešķiršana katram digitālajam resursam novērš «trokšņaino kaimiņu» problēmu, taču ātri izsmeļ darbības budžetu. Standarta Docker izvietojumi atrisina izmaksu jautājumu, darbinot vairākas vietnes vienā operētājsistēmas kodolā, taču noklusējuma iestatījumi rada bīstamus izolācijas riskus. Ja viena nomnieka lietotnē rodas kļūdains skripts vai ļaunprātīgs ielaušanās mēģinājums, visas pārējās uz šī resursdatora izvietotās lietotnes ir pakļautas riskam.

Izmantojiet šo tehnisko soli pa solim plānu, lai konfigurētu stingru daudznomnieku izolāciju programmā Docker. Ieviesiet šos piecus operatīvos soļus, lai aizsargātu sistēmas stabilitāti, izolētu nomnieku datus un pārvērstu tehniskās infrastruktūras izvēles skaidrā biznesa vērtībā vadības acīs.

---

1. Ieviesiet stingras resursu kvotas, izmantojot cgroups

Nekavējoties iestatiet skaidrus procesora (CPU), atmiņas un diska I/O ierobežojumus katram konteineram. Kad vairāki nomnieki dala vienu resursdatoru, neierobežoti konteineri konkurē par sistēmas resursiem. Viens kļūdains datubāzes vaicājums vai augstas satiksmes kampaņa var izsmelt visu resursdatora atmiņas apjomu, liekot Linux Out-Of-Memory (OOM) killer mehānismam pārtraukt patvaļīgus sistēmas procesus.

Linux vadības grupas (cgroups) nosaka, cik daudz skaitļošanas jaudas konkrēts konteiners drīkst patērēt. Ieviesiet šīs robežas tieši savās izvietošanas konfigurācijās:

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

• Atmiņas ierobežojumi (limits.memory): Nosaka stingros griestus. Ja konteiners pārsniedz 512 megabaitus, kodols pārtrauc procesus šajā konteinerā, neietekmējot blakus esošos nomniekus.
• Atmiņas rezervācijas (reservations.memory): Garantē bāzes atmiņas piešķīrumu, lai zemas satiksmes lietotnes saglabātu ātru reakcijas laiku.
• CPU ierobežojumi (limits.cpus): Ierobežo konteineru līdz maksimālajai pieejamo procesora kodolu daļai, novēršot situāciju, kad viens nomnieks noslogo visu CPU.

Pamatojot šo arhitektūru vadībai, salīdziniet cgroups ar automatizētiem digitālajiem elektrības skaitītājiem. Tāpat kā nomnieki biroju ēkā maksā par savu individuālo elektroenerģijas patēriņu, nevis pārslogo galveno drošinātāju, cgroups nodrošina, ka viena noslogota mērķlapa nekad neaptur cita klienta pieteikumu vākšanas portālu. Padziļinātam ieskatam arhitektūras kompromisos izlasiet mūsu ceļvedi par daudznomnieku arhitektūras izstrādi.

---

2. Segmentējiet nomnieku procesus ar nosaukumvietām un lietotājiem bez root tiesībām

Nekad nedarbiniet konteinera procesus kā noklusējuma root lietotāju. Standarta Linux konteineru vidēs root tiesības konteinerā atbilst root tiesībām uz resursdatora kodola, ja vien nav iestatīta eksplīcīta pāradresācija. Ja uzbrucējs iekļūst tīmekļa lietotnē, kas darbojas ar root tiesībām, viņš iegūst paaugstinātas privilēģijas pār kopīgoto resursdatoru.

Nodrošiniet procesu izolāciju, izmantojot lietotāju nosaukumvietas un procesu izpildi bez root tiesībām:

1. Definējiet neprivileģētus izpildlaika lietotājus: Izveidojiet atsevišķus servisa lietotājus ar zemām privilēģijām savos Dockerfile failos.

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

2. Iespējojiet lietotāju nosaukumvietas (userns-remap): Konfigurējiet Docker dēmonu (/etc/docker/daemon.json), lai pāradresētu konteinera lietotāju ID uz neprivileģētu diapazonu resursdatorā.

   {
     "userns-remap": "default"
   }
   

Linux nosaukumvietas (namespaces) sadala sistēmas redzamību. Procesu ID (PID) nosaukumvieta nodrošina, ka Nomnieks A nevar redzēt, ietekmēt vai pārtraukt Nomnieka B procesus. Pievienošanas (MNT) nosaukumvieta piešķir katram nomniekam izolētu failu sistēmas skatu, savukārt IPC nosaukumvietas bloķē neatļautu starpprocesu komunikāciju.

Lietotāju nosaukumvietu pāradresēšana novērš konteinera apiešanas vektorus: process, kas sava konteinera iekšienē uzskata sevi par root (UID 0), resursdatorā tiek piesaistīts neprivileģētam ID (piemēram, UID 165536). Ja ievainojamība apiet konteinera robežas, uzbrucējs nonāk neprivileģētā čaulā, nespējot mainīt resursdatora konfigurācijas vai piekļūt blakus esošo nomnieku direktorijiem.

---

3. Noņemiet kodola privilēģijas un ieviesiet tikai lasāmas failu sistēmas

Samaziniet pieejamās Linux iespējas (capabilities) un padariet konteinera saknes failu sistēmu nemaināmu palaišanas brīdī. Noklusējuma konteineru izpildlaiki piešķir aptuveni duci Linux kodola iespēju, no kurām lielākā daļa tīmekļa lietotnēm nekad nav vajadzīga. Pārmērīgas iespējas sniedz uzbrucējiem rīkus tīkla maršrutēšanas manipulēšanai, sistēmas pulksteņa maiņai vai failu piekļuves kontroļu apiešanai.

Nostipriniet konteinerus, noņemot visas noklusējuma iespējas un pievienojot atpakaļ tikai būtiskākos darbības karodziņus:

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: Noņem visas kodola iespējas no konteinera procesa.
• cap_add: - NET_BIND_SERVICE: Eksplīcīti atļauj piesaisti privileģētiem portiem (piemēram, 80 un 443), vienlaikus bloķējot neapstrādātu tīkla ligzdu manipulācijas.
• read_only: true: Pievieno visu konteinera saknes failu sistēmu tikai lasīšanas režīmā. Uzbrucēji nevar lejupielādēt ļaunprātīgus bināros failus, mainīt PHP skriptus vai labot tīmekļa servera konfigurācijas failus.
• tmpfs: Piešķir pagaidu atmiņas direktorijus nepieciešamajiem darba failiem (piemēram, /tmp), vienlaikus bloķējot bināro failu izpildi (noexec) un privilēģiju paaugstināšanu (nosuid).

Pielietojiet drošās skaitļošanas režīma (seccomp) filtrus un drošības moduļus, piemēram, AppArmor vai SELinux, lai pārtvertu un ierobežotu sistēmas izsaukumus kopīgotajam resursdatora kodolam. Ja jūsu komanda pārvalda pielāgotas lietotņu būvēšanas darbplūsmas, sekojiet mūsu strukturētajiem soļiem par Docker konteineru nocietināšanu visos izvietošanas procesos.

---

4. Sadaliet tīklus starp nomnieku vidēm

Atspējojiet noklusējuma tilta (bridge) tīklu un izveidojiet pielāgotus, izolētus programmatiski definētus tīklus katra nomnieka kopai. Pēc noklusējuma konteineri standarta Docker tilta tīklā var atrast viens otru un sazināties, izmantojot iekšējās IP adreses. Ievainojamība viena nomnieka mārketinga mikropakalpojumā ļauj brīvi pārvietoties uz jebkuru citu iekšējo datubāzi un lietotni šajā resursdatorā.

Pilnībā izolējiet nomnieku datplūsmu, deklarējot neatkarīgus tīkla tiltus katram nomniekam:

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

• Nomnieku izolācija: alpha_app un alpha_db sazinās tikai caur tenant_alpha_net. beta_app nevar piekļūt alpha_db, pat ja uzbrucējs skenē iekšējo apakštīklu.
• Iekšējais karodziņš (internal: true): Neļauj datubāzu tīkliem maršrutēt datplūsmu tieši uz ārējo internetu, ierobežojot ienākošo un izejošo piekļuvi tikai lietotņu konteineriem.
• Apgrieztā starpniekservera (Reverse Proxy) vārteja: Tikai ienākošais starpniekserveris pieslēdzas pie public_gateway_net, lai maršrutētu ienākošos HTTP/HTTPS pieprasījumus uz norādīto nomnieka konteineru pēc resursdatora nosaukuma.

Augstākas drošības vidēm apsveriet Docker Enhanced Container Isolation (ECI) režīmus vai izpildlaikus, piemēram, Sysbox, kas automātiski ievieš stingrākas lietotāju nosaukumvietu robežas un virtualizētas /proc un /sys failu sistēmas bez sarežģītas manuālas tīklu skriptēšanas.

---

5. Izveidojiet objektīvu daudznomnieku lēmumu matricu

Noraidiet pieņēmumu, ka visiem digitālajiem resursiem nepieciešamas atsevišķas virtuālās mašīnas. Mārketinga vadītāji bieži pieņem, ka aparatūras līmeņa VM izolācija ir vienīgais aizsargājamais drošības modelis. Praksē atsevišķu virtuālo mašīnu izveide vieglām mērķlapām vai īslaicīgām kampaņu vietnēm rada milzīgu izmaksu pieaugumu un uzturēšanas slogu, neuzlabojot tīmekļa lietotņu drošību.

Izmantojiet šo salīdzināšanas matricu, lai novērtētu darba slodzes prasības un prezentētu racionālu izvietošanas stratēģiju lēmumu pieņēmējiem:

Izolācijas līmenis	Pamattehnoloģija	Drošības robeža	Resursu papildpatēriņš	Labākais pielietojums
Kopīgotā steka konteineri	Nosaukumvietas un cgroups vienā OS	Loģiska OS līmeņa izolācija	Ļoti zems	Liela apmeklējuma mērķlapas, iekšējā testēšana, pagaidu kampaņu vietnes
Nocietināti konteineri (ECI / Sysbox)	Lietotāju nosaukumvietas, AppArmor, tikai lasāma saknes sistēma	Uzlabota OS līmeņa izolācija un virtualizācija	Zems	Aģentūru vairāku klientu uzturēšana, autentificēti portāli, sensitīvas mārketinga veidlapas
Dedikētas virtuālās mašīnas (VM)	Hipervizora aparatūras virtualizācija	Stingra aparatūras/kodola nošķiršana	Augsts	Maksājumu apstrāde, regulēti HIPAA/PCI dati, neuzticama pielāgota koda izpilde
Hibrīda risinājums (konteineri dedikētās VM)	Nocietināti konteineri konkrēta nomnieka VM	Daudzlīmeņu aparatūras un OS robežas	Mērens līdz augsts	Augsta līmeņa uzņēmumu klienti ar stingrām līguma atbilstības prasībām

Novērtējiet katru projektu pēc stingriem kritērijiem pirms infrastruktūras budžeta piešķiršanas:

1. Datu sensitivitāte: Vai projektā tiek glabāti regulēti dati (piemēram, maksājumu karšu dati vai medicīniskā informācija)? Ja jā, izvietojiet to atsevišķā VM.
2. Koda izcelsme: Vai izvietojat standartizētu, komandas pārbaudītu kodu, vai arī atļaujat nepārbaudītus trešo pušu spraudņus? Standarta kods ir piemērots nocietinātiem konteineriem; nepārbaudītam trešo pušu kodam nepieciešama hipervizora izolācija.
3. Budžets un mūža ilgums: Sezonālām mērķlapām un uzņēmuma pamatvietnēm nocietināta daudznomnieku konteineru vide nodrošina maksimālu veiktspēju par katru ieguldīto eiro.

Prezentējot infrastruktūras plānus vadībai, izmantojiet mūsu ceļvedi par izvērtēšanu, kad klientiem nepieciešamas dedikētas virtuālās mašīnas, lai pamatotu savus ieteikumus ar skaidriem līmeņu argumentiem.

---

Secinājums: Drošības kontroļu pārvēršana biznesa atdevē (ROI)

Daudznomnieku Docker vides aizsardzībai nav nepieciešams milzīgs uzņēmuma mākoņarhitektūras budžets. Tai ir nepieciešama rūpīga un disciplinēta operētājsistēmas kontroļu piemērošana.

Pārrunājot infrastruktūru ar vadītājiem, formulējiet šīs tehniskās konfigurācijas trīs vadības rādītāju ietvaros:

• Izmaksu efektivitāte: Daudznomnieku konteineri ļauj uzturēt desmitiem mārketinga vietņu ar nelielu daļu no skaitļošanas resursiem, ko prasītu atsevišķas virtuālās mašīnas.
• Darbspējas laika (uptime) aizsardzība: Vadības grupas (cgroups) garantē, ka sezonas kampaņas satiksmes pieaugums neietekmēs pamata zīmola vietņu veiktspēju.
• Ietekmes rādiusa ierobežošana: Tikai lasāmas failu sistēmas, noņemtas privilēģijas un izolēti tīkla tilti nodrošina, ka vienas vietnes kompromitēšana neļauj piekļūt blakus esošajām klientu datubāzēm vai resursdatora pārvaldībai.

Ieviesiet šos aizsargmehānismus sistemātiski savos konteineru šablonos. Jūs iegūsiet augstas veiktspējas un rentablu infrastruktūru, kas atbilst gan inženiertehniskajiem drošības standartiem, gan vadības budžeta prasībām.