Patiesas vairāklietotāju izolācijas sasniegšana Docker

Kopsavilkums

Docker konteineri koplieto resursdatora kodolu, kas var būt drošības problēma vairāklietotāju vidēs, kur lietotāji, iespējams, neuzticas viens otram. Šis raksts izskaidro izolācijas trūkumus noklusējuma Docker iestatījumos un sniedz konkrētus soļus izolācijas nostiprināšanai, izmantojot Linux nosaukumvietas, cgroups, lietotāju nosaukumvietas, seccomp, AppArmor un aparatūras virtualizāciju. Jūs uzzināsiet, kā konfigurēt katram lietotājam paredzētus Docker dēmonus, izmantot smilškastes rīkus, piemēram, gVisor vai Firecracker, lai nodrošinātu spēcīgāku izolāciju, un orķestrēt ar Kubernetes vairāklietotāju risinājumiem. Mēs arī apskatīsim, kā izvēlēties pareizo infrastruktūras pakalpojumu sniedzēju, kas piedāvā KVM balstītu virtualizāciju papildu atdalīšanas slānim. Beigās jums būs plāns, kā nodrošināt drošu vairāklietotāju darba slodzes Docker.

Ja vairāki lietotāji tiek izvietoti vienā Docker resursdatorā, noklusējuma konteineru izolācija, kas balstīta uz Linux nosaukumvietām un cgroups, bieži vien nav pietiekama. Viena lietotāja konteinera izbēgšana var apdraudēt visu resursdatoru un visus pārējos konteinerus. Šī problēma ir īpaši aktuāla koplietotā mitināšanā, SaaS platformās vai jebkurā scenārijā, kur neuzticams kods darbojas blakus jūsu kodam. Labā ziņa: jūs varat sakraut vairākas izolācijas metodes, lai izveidotu stiprinātu vairāklietotāju vidi. Šī rokasgrāmata apraksta sešus praktiskus soļus, sākot no vienkāršiem risinājumiem, piemēram, lietotāju nosaukumvietu, līdz progresīviem pasākumiem, piemēram, smilškastes izpildlaikiem un infrastruktūras izvēlēm.

Izpratne par Docker noklusējuma izolāciju

Docker izmanto Linux nosaukumvietas, lai izolētu procesus, tīklu, failu sistēmu un citus resursus. Cgroups ierobežo CPU, atmiņu un I/O. Bet tie koplieto vienu kodolu — ievainojamība kodolā var ietekmēt visus konteinerus. Patiesai vairāklietotāju darbībai, īpaši ar neuzticamiem lietotājiem, jums ir nepieciešama slāņveida aizsardzība. Kā apspriests Daudzlietotāju Docker arhitektūras dizains: pareizā izolācijas līmeņa izvēle, izolācijas līmeņi svārstās no vāja (tikai nosaukumvietas) līdz spēcīgam (aparatūras virtualizācija). Sāksim ar vājāko.

1. solis: Iespējot lietotāju nosaukumvietas

Pēc noklusējuma root konteinerī tiek kartēts uz root resursdatorā. Konteinera izbēgšana dod pilnīgu piekļuvi resursdatoram. Lietotāju nosaukumvietas pārkartē konteinera root uz ārēju lietotāju, kas nav root. Iespējojiet to globāli ar dockerd --userns-remap=default vai atsevišķam konteinerim ar --userns=host. Šis vienkāršais solis novērš daudzus privilēģiju paaugstināšanas uzbrukumus. Testējiet savas lietojumprogrammas: dažas, kurām nepieciešamas resursdatora līmeņa privilēģijas (piem., failu sistēmu montāža), var neizdoties. Drupal vai WordPress vietnēm tas parasti ir droši.

2. solis: Pielietot Seccomp un AppArmor profilus

Seccomp ierobežo sistēmas izsaukumus, ko konteiners var veikt. Docker noklusējuma seccomp profils bloķē bīstamus syscall, piemēram, mount un reboot. Vairāklietotāju vidēs vēl vairāk savelciet to — bloķējiet reti lietotus syscall, ko izmanto izbēgšanas rīki. Līdzīgi, AppArmor var ierobežot konteinera procesus. Izveidojiet pielāgotu AppArmor profilu, kas noliedz rakstīšanas piekļuvi kodola saskarnēm un ierobežo failu ceļus. Abi tiek iestatīti ar --security-opt karogiem. Apvienojiet tos slāņveida aizsardzībai.

3. solis: Izmantot katram lietotājam atsevišķus Docker dēmonus

Viena Docker dēmona darbināšana visiem lietotājiem ir riskanta — jebkura konteinera izbēgšana var piekļūt dēmona ligzdai. Izolējiet dēmonus katram lietotājam, izmantojot Docker-in-Docker (DinD) vai attālos dēmona galapunktus. Piemēram, palaidiet Docker dēmonu konteinerī ar --privileged (bet tas vājina izolāciju). Labāka pieeja: darbiniet atsevišķus dēmonus atsevišķās virtuālajās mašīnās vai izmantojiet Docker eksperimentālo --group funkciju ar lietotāju nosaukumvietām. Orķestrēšanai Kubernetes nosaukumvietu izolācija ir praktiskāka, kā aprakstīts Aizsardzība pret konteinera izbēgšanu: praktiska rokasgrāmata Docker izolācijai vairāklietotāju mitināšanā.

4. solis: Apsvērt smilškastes izpildlaikus

Ja Linux kodols pats par sevi ir neuzticams, izmantojiet smilškastes izpildlaiku, kas pievieno vieglu VM slāni. gVisor (runsc) pārtver sistēmas izsaukumus un realizē savu kodolu, savukārt Firecracker izmanto mikro-VM ar aparatūras virtualizāciju. Abi integrējas ar Docker, izmantojot containerd izpildlaikus. Piemēram, pievienojiet "runtimes": {"runsc": {}} Docker dēmona konfigurācijā un palaidiet konteinerus ar --runtime=runsc. Veiktspējas pārspīlējums ir 5–15%, bet izolācija ir ievērojami spēcīgāka. Ideāli augstas drošības vairāklietotāju iestatījumiem.

5. solis: Orķestrēt ar Kubernetes un drošības politikām

Kubernetes nodrošina vietējo vairāklietotāju atbalstu caur nosaukumvietām, Pod drošības standartiem un tīkla politikām. Definējiet katram lietotājam atsevišķas nosaukumvietas ar resursu kvotām un ieviesiet ierobežotas pod drošības kontekstus (noņemiet visas iespējas, tikai lasāmu saknes failu sistēmu). Uzņemšanas kontrolieri, piemēram, OPA/Gatekeeper, var bloķēt nepareizas konfigurācijas. Ja pārvaldāt daudzus lietotājus, Kubernetes automatizē izolācijas ieviešanu. Par ražošanas mēroga orķestrēšanu skatiet Beyond Docker Compose: Orķestrējot ražošanai gatavas konteinerizētas lietojumprogrammas.

6. solis: Izvēlēties pareizo mitināšanas pakalpojumu sniedzēju

Jūsu infrastruktūras pakalpojumu sniedzēja hipervizoram ir nozīme. Docker koplietotā mitināšanā (OpenVZ) nodrošina vāju izolāciju — viens lietotājs var redzēt citus procesus. Dodiet priekšroku pakalpojumu sniedzējiem, kas izmanto KVM vai VMware, kuri nodrošina aparatūras līmeņa atdalīšanu. Tādi pakalpojumu sniedzēji kā DigitalOcean, Kamatera vai AWS piedāvā KVM balstītus VPS ar rezervētiem resursiem. Fiziskajiem serveriem pārliecinieties, ka BIOS līmeņa virtualizācija ir iespējota ligzdotiem konteineriem. Pakalpojumu sniedzējs, kas izolē lietotājus hipervizora līmenī, papildina jūsu konteineru izolāciju. Kā detalizēts Docker izolācijas apgūšana drošai un efektīvai tīmekļa mitināšanai, resursdatora OS arī jābūt stiprinātai ar minimālu uzbrukuma virsmu.

Brīdinājumi un kompromisi

Katrs papildu slānis palielina sarežģītību un veiktspējas izmaksas. Lietotāju nosaukumvietas var izjaukt resursdatora montāžas sējumu. Seccomp profiliem nepieciešama skaņošana atbilstoši lietojumprogrammai. Smilškastes izpildlaiki, piemēram, gVisor, neatbalsta visus syscall — jūsu lietotne var nedarboties. Katram lietotājam atsevišķi Docker dēmoni palielina atmiņas pārspīlējumu. Izvēlieties izolācijas līmeni, kas atbilst jūsu draudu modelim: uzticamiem lietotājiem var pietikt ar noklusējuma nosaukumvietām; publiskajām SaaS ieguldiet izpildlaika smilškastēs un Kubernetes politikās. Rūpīgi testējiet pirms ražošanas.

Secinājums

Patiesu vairāklietotāju izolāciju Docker var sasniegt, slāņojot vairākus kodola funkcijas, izpildlaika smilškastes un orķestrēšanas kontroles. Sāciet ar lietotāju nosaukumvietām un seccomp, pēc tam pārejiet pie katram lietotājam atsevišķiem dēmoniem vai smilškastes izpildlaikiem. Liela mēroga risinājumiem Kubernetes nodrošina politiku vadītu izolāciju. Vienmēr savienojiet ar hipervizora līmeņa atdalītu resursdatoru no cienījama pakalpojumu sniedzēja. Neviena tehnika nav absolūti droša, bet to kombinācija rada spēcīgu aizsardzību. Jūsu lietotāji jums pateiksies — un arī jūsu drošības audits.