Pasiekiant tikrą kelių nuomininkų izoliaciją Docker

Santrauka

Docker konteineriai dalijasi pagrindinio kompiuterio branduoliu, o tai gali kelti saugumo pavojų kelių nuomininkų aplinkose, kur nuomininkai gali nepasitikėti vienas kitu. Šiame straipsnyje paaiškinamos numatytosios Docker sąrankos izoliacijos spragos ir pateikiami konkretūs žingsniai, kaip sustiprinti izoliaciją naudojant Linux vardų sritis, cgroups, vartotojų vardų sritis, seccomp, AppArmor ir aparatinę virtualizaciją. Sužinosite, kaip konfigūruoti kiekvieno nuomininko Docker demonus, naudoti smėlio dėžės įrankius, tokius kaip gVisor ar Firecracker, siekiant tvirtesnės izoliacijos, ir orkestruoti su Kubernetes kelių nuomininkų aplinkoms. Taip pat aptarsime, kaip pasirinkti tinkamą infrastruktūros teikėją, siūlantį KVM pagrįstą virtualizaciją, kad būtų užtikrintas papildomas atskyrimo sluoksnis. Galiausiai turėsite planą, kaip saugiai vykdyti kelių nuomininkų darbo krūvius su Docker.

Kai tame pačiame Docker kompiuteryje talpinami keli nuomininkai, numatytoji konteinerių izoliacija, pagrįsta Linux vardų sritimis ir cgroups, dažnai nepakanka. Vieno nuomininko konteinerio pabėgimas gali pažeisti visą kompiuterį ir visus kitus konteinerius. Ši problema ypač aktuali bendrame talpinime, SaaS platformose ar bet kurioje situacijoje, kai nepatikimas kodas veikia šalia jūsų kodo. Geros naujienos: galite sukrauti kelias izoliacijos technologijas, kad sukurtumėte sustiprintą kelių nuomininkų aplinką. Šis vadovas apima šešis praktinius veiksmus – nuo lengvai įgyvendinamų, tokių kaip vartotojų vardų sritys, iki pažangių priemonių, tokių kaip smėlio dėžės vykdymo laikas ir infrastruktūros pasirinkimai.

Docker numatytoji izoliacija

Docker naudoja Linux vardų sritis procesams, tinklui, failų sistemai ir kitiems ištekliams izoliuoti. Cgroups riboja procesoriaus, atminties ir I/O naudojimą. Tačiau visi jie naudoja vieną branduolį – branduolio pažeidžiamumas gali paveikti visus konteinerius. Tikrai kelių nuomininkų aplinkoms, ypač su nepatikimais nuomininkais, reikia gynybos gilumoje. Kaip aptarta straipsnyje Projektuojant kelių nuomininkų Docker architektūrą: tinkamo izoliacijos lygio pasirinkimas, izoliacijos lygiai svyruoja nuo silpnos (tik vardų sritys) iki stiprios (aparatinė virtualizacija). Pradėkime nuo silpniausios.

1 žingsnis: Įjunkite vartotojų vardų sritis

Pagal numatytuosius nustatymus root vartotojas konteineryje atitinka root vartotoją kompiuteryje. Konteinerio proveržis suteikia visą prieigą prie kompiuterio. Vartotojų vardų sritys susieją konteinerio root vartotoją su ne root vartotoju išorėje. Įjunkite globaliai naudodami dockerd --userns-remap=default arba konteineriui naudodami --userns=host. Šis paprastas veiksmas pašalina daugelį privilegijų didinimo atakų. Išbandykite savo programas: kai kurios, kurioms reikalingos kompiuterio lygio privilegijos (pvz., failų sistemų prijungimas), gali sugesti. Drupal ar WordPress svetainėms tai paprastai yra saugu.

2 žingsnis: Taikykite Seccomp ir AppArmor profilius

Seccomp riboja sistemos iškvietimus, kuriuos konteineris gali atlikti. Docker pateikia numatytąjį seccomp profilį, kuris blokuoja pavojingus sistemos iškvietimus, pvz., mount ir reboot. Kelių nuomininkų aplinkose sugriežtinkite – blokuokite retus sistemos iškvietimus, kuriuos naudoja pabėgimo įrankiai. Panašiai AppArmor gali apriboti konteinerio procesus. Sukurkite pasirinktinį AppArmor profilį, kuris uždraustų rašymo prieigą prie branduolio sąsajų ir apribotų failų kelius. Abu nustatomi naudojant --security-opt vėliavėles. Sujunkite juos sluoksniuotai gynybai.

3 žingsnis: Naudokite kiekvieno nuomininko Docker demonus

Vieno Docker demono naudojimas visiems nuomininkams yra rizikingas – bet koks konteinerio pabėgimas gali pasiekti demono lizdą. Izoliuokite demonus pagal nuomininką naudodami Docker-in-Docker (DinD) arba nuotolinius demono galinius taškus. Pavyzdžiui, paleiskite Docker demoną konteineryje su --privileged (bet tai silpnina izoliaciją). Geresnis būdas: paleisti atskirus demonus atskirose virtualiose mašinose arba naudoti eksperimentinę Docker --group funkciją su vartotojų vardų sritimis. Orkestruojant, Kubernetes vardų sričių izoliacija yra praktiškesnė, kaip aptarta straipsnyje Kaip apsisaugoti nuo konteinerio pabėgimo: praktinis Docker izoliacijos vadovas kelių nuomininkų talpinimui.

4 žingsnis: Apsvarstykite smėlio dėžės vykdymo laiką

Kai pats Linux branduolys nepatikimas, naudokite smėlio dėžės vykdymo laiką, kuris prideda lengvą VM sluoksnį. gVisor (runsc) perima sistemos iškvietimus ir įgyvendina savo branduolį, o Firecracker naudoja mikro-VM su aparatine virtualizacija. Abu integruojasi su Docker per containerd vykdymo laikus. Pavyzdžiui, pridėkite "runtimes": {"runsc": {}} prie Docker demono konfigūracijos ir paleiskite konteinerius su --runtime=runsc. Našumo sąnaudos yra 5–15%, bet izoliacija žymiai stipresnė. Idealu didelio saugumo kelių nuomininkų sąrankoms.

5 žingsnis: Orkestruokite su Kubernetes ir saugumo politika

Kubernetes suteikia vietinę kelių nuomininkų funkciją per vardų sritis, Pod saugumo standartus ir NetworkPolicies. Apibrėžkite kiekvieno nuomininko vardų sritis su išteklių kvotomis ir vykdykite apribotus pod saugumo kontekstus (pašalinkite visas galimybes, tik skaitymo šakninę failų sistemą). Priėmimo kontrolieriai, tokie kaip OPA/Gatekeeper, gali blokuoti neteisingas konfigūracijas. Jei valdote daug nuomininkų, Kubernetes automatizuoja izoliacijos vykdymą. Gamybos masto orkestravimui žr. Už Docker Compose ribų: gamybai paruoštų konteinerizuotų programų orkestravimas.

6 žingsnis: Pasirinkite tinkamą talpinimo teikėją

Jūsų infrastruktūros teikėjo hipervizorius yra svarbus. Docker bendrame talpinime (OpenVZ) suteikia silpną izoliaciją – vienas nuomininkas gali matyti kitų procesus. Pirmenybę teikite teikėjams, naudojantiems KVM ar VMware, kurie siūlo aparatinio lygio atskyrimą. Tokie teikėjai kaip DigitalOcean, Kamatera ar AWS siūlo KVM pagrįstus VPS su skirtais ištekliais. Fiziniams serveriams įsitikinkite, kad BIOS lygio virtualizacija įjungta, kad būtų galima vykdyti įdėtus konteinerius. Teikėjas, kuris izoliuoja nuomininkus hipervizoriaus lygiu, papildo jūsų konteinerių izoliaciją. Kaip išsamiai aprašyta straipsnyje Įvaldykite Docker izoliaciją saugiam ir efektyviam žiniatinklio talpinimui, pagrindinės OS taip pat turi būti sustiprinta, sumažinant atakos paviršių.

Įspėjimai ir kompromisai

Kiekvienas papildomas sluoksnis padidina sudėtingumą ir našumo sąnaudas. Vartotojų vardų sritys gali sugadinti prijungtus tomus. Seccomp profilius reikia pritaikyti programai. Smėlio dėžės vykdymo laikai, kaip gVisor, nepalaiko visų sistemos iškvietimų – jūsų programa gali neveikti. Kiekvieno nuomininko Docker demonai didina atminties naudojimą. Pasirinkite izoliacijos lygį, atitinkantį jūsų grėsmės modelį: patikimiems nuomininkams gali pakakti numatytųjų vardų sričių; viešai SaaS investuokite į vykdymo laiko smėlio dėžes ir Kubernetes politikas. Prieš gamybą atlikite išsamius bandymus.

Išvada

Tikra kelių nuomininkų izoliacija Docker yra pasiekiama sujungiant kelias branduolio funkcijas, vykdymo laiko smėlio dėžes ir orkestravimo valdiklius. Pradėkite nuo vartotojų vardų sričių ir seccomp, tada pereikite prie kiekvieno nuomininko demonų arba smėlio dėžės vykdymo laikų. Dideliu mastu Kubernetes užtikrina politikomis pagrįstą izoliaciją. Visada derinkite su hipervizoriaus lygiu atskirtu kompiuteriu iš patikimo teikėjo. Nė viena technika nėra nepriekaištinga, tačiau jų derinimas sukuria tvirtą gynybą. Jūsų nuomininkai jums padėkos – ir jūsų saugumo auditas taip pat.