Tõelise mitmeüürniku isoleerimise saavutamine Dockeris

Kokkuvõte

Dockeri konteinerid jagavad hosti kerneli, mis võib olla turvarisk mitmeüürniku keskkondades, kus üürnikud ei pruugi üksteist usaldada. See artikkel selgitab isoleerimise lünki vaikimisi Dockeri seadistustes ja pakub konkreetseid samme isoleerimise tugevdamiseks Linuxi nimeruumide, cgroupide, kasutajanimeruumide, seccomp, AppArmor ja riistvaravirtualiseerimise abil. Sa õpid, kuidas seadistada üürnikupõhiseid Dockeri deemoneid, kasutada liivakastimistööriistu nagu gVisor või Firecracker tugevama isoleerimise jaoks ning orkestreerida Kubernetes'iga mitmeüürniku keskkonda. Samuti käsitleme õige infrastruktuuriteenuse pakkuja valimist, kes pakub KVM-põhist virtualiseerimist täiendava eralduskihina. Lõpuks on sul plaan turvaliste mitmeüürniku töökoormuste käitamiseks Dockeriga.

Kui majutad mitut üürnikku ühel Dockeri hostil, ei piisa vaikimisi konteineri isoleerimisest – mis põhineb Linuxi nimeruumidel ja cgroupidel – sageli. Ühe üürniku konteinerist põgenemine võib ohustada kogu hosti ja kõiki teisi konteinereid. See probleem on eriti terav jagatud majutuses, SaaS platvormidel või muudes stsenaariumides, kus usaldamatu kood töötab koos sinu omaga. Hea uudis: saad virnastada mitu isoleerimistehnikat, et luua tugevdatud mitmeüürniku keskkond. See juhend viib läbi kuus praktilist sammu, alates lihtsast nagu kasutajanimeruumid kuni edasijõudnudeni nagu liivakastimise käituskeskkonnad ja infrastruktuuri valikud.

Dockeri vaikimisi isoleerimise mõistmine

Docker kasutab Linuxi nimeruume protsesside, võrgu, failisüsteemi ja muude ressursside isoleerimiseks. Cgroupid piiravad protsessori, mälu ja sisend-väljundit. Kuid need jagavad ühte kerneli – haavatavus kernelis võib mõjutada kõiki konteinereid. Tõeliseks mitmeüürniku keskkonnaks, eriti usaldamatute üürnikega, vajad kaitse sügavust. Nagu arutatud artiklis Mitmeüürniku Dockeri arhitektuuri kavandamine: õige isoleerimistaseme valimine, ulatuvad isoleerimistasemed nõrgast (ainult nimeruumid) tugevani (riistvaravirtualiseerimine). Ehitame üles nõrgemast alustades.

1. samm: Luba kasutajanimeruumid

Vaikimisi vastendub root konteineri sees root-iga hostis. Konteinerist põgenemine annab täieliku juurdepääsu hostile. Kasutajanimeruumid vastendavad konteineri root-i ümber mitteroot-kasutajaks väljaspool. Luba see globaalselt käsuga dockerd --userns-remap=default või konteineripõhiselt lipuga --userns=host. See lihtne samm kõrvaldab paljud privilegeerimise rünnakud. Testi oma rakendusi: mõned, mis nõuavad hostitaseme õigusi (nt failisüsteemide ühendamine), võivad katki minna. Drupal või WordPress saitide puhul on see tavaliselt ohutu.

2. samm: Rakenda seccomp ja AppArmor profiilid

Seccomp piirab süsteemikutseid, mida konteiner saab teha. Docker tarnib vaikimisi seccomp profiili, mis blokeerib ohtlikud süsteemikutsed nagu mount ja reboot. Mitmeüürniku keskkonnas pinguta seda veelgi – blokeeri ebatavalised süsteemikutsed, mida põgenemistööriistad kasutavad. Samamoodi saab AppArmor piirata konteineri protsesse. Loo kohandatud AppArmor profiil, mis keelab kirjutamisjuurdepääsu kerneli liidestele ja piirab failiteid. Mõlemad seatakse lipuga --security-opt. Kombineeri need kihiliseks kaitseks.

3. samm: Kasuta üürnikupõhiseid Dockeri deemoneid

Ühe Dockeri deemonina kõigi üürnike jaoks on riskantne – igasugune konteinerist põgenemine võib pääseda deemonipesale. Isoleeri deemonid üürniku kohta, kasutades Docker-in-Docker (DinD) või kaugdeemoni lõpp-punkte. Näiteks käivita Dockeri deemon konteineri sees lipuga --privileged (kuid see nõrgendab isoleerimist). Parem lähenemine: käivita eraldi deemonid eraldi virtuaalmasinates või kasuta Dockeri eksperimentaalset --group funktsiooni koos kasutajanimeruumidega. Orkestreerimisel on Kubernetes'i nimeruumipõhine isoleerimine praktilisem, nagu käsitletud artiklis Konteinerist põgenemise vastu kaitsmine: praktiline juhend Dockeri isoleerimiseks mitmeüürniku majutuses.

4. samm: Kaalu liivakastimise käituskeskkondi

Kui Linuxi kernel ise on usaldamatu, kasuta liivakastimise käituskeskkonda, mis lisab kerge VM-kihi. gVisor (runsc) peatab süsteemikutsed ja rakendab oma kerneli, samas kui Firecracker kasutab mikro-VM-e riistvaravirtualiseerimisega. Mõlemad integreeruvad Dockeriga containerd käituskeskkondade kaudu. Näiteks lisa "runtimes": {"runsc": {}} Dockeri deemoni seadesse ja käivita konteinerid käsuga --runtime=runsc. Toimivuse ülekulu on 5–15%, kuid isoleerimine on tunduvalt tugevam. Ideaalne kõrge turvalisusega mitmeüürniku seadistustes.

5. samm: Orkestreeri Kubernetes'i ja turvapoliitikatega

Kubernetes pakub loomulikku mitmeüürniku tuge nimeruumide, Pod-turvastandardite ja võrgupoliitikate kaudu. Määratle üürnikupõhised nimeruumid ressursikvootidega ja jõusta piiratud pod-turvakontekste (eemalda kõik võimalused, kirjutuskaitstud juurfailisüsteem). Sisselaskekontrollijad nagu OPA/Gatekeeper võivad blokeerida valeseadistused. Kui haldad palju üürnikke, automatiseerib Kubernetes isoleerimise jõustamise. Tootmisühise orkestreerimise kohta vaata artiklit Beyond Docker Compose: tootmisvalmis konteineriseeritud rakenduste orkestreerimine.

6. samm: Vali õige majutusteenuse pakkuja

Sinu infrastruktuuriteenuse pakkuja hüperviisor mängib rolli. Docker jagatud majutuses (OpenVZ) annab nõrga isoleerimise – üks üürnik võib näha teisi protsesse. Eelista pakkujaid, kes kasutavad KVM-i või VMware't, mis pakuvad riistvarataseme eraldust. Pakkujad nagu DigitalOcean, Kamatera või AWS pakuvad KVM-põhiseid VPS-e pühendatud ressurssidega. Raudbetooni puhul veendu, et BIOS-taseme virtualiseerimine on sisse lülitatud pesastatud konteinerite jaoks. Pakkuja, kes isoleerib üürnikud hüperviisori kihil, täiendab sinu konteineri isoleerimist. Nagu üksikasjalikult kirjeldatud artiklis Dockeri isoleerimise valdamine turvaliseks ja tõhusaks veebimajutuseks, tuleks ka hosti OS tugevdada minimaalse ründepinnaga.

Hoiatused ja kompromissid

Iga lisakiht lisab keerukust ja jõudluskulu. Kasutajanimeruumid võivad katki teha hosti ühendatud köited. Seccomp profiilid nõuavad häälestamist rakenduse põhjal. Liivakastimise käituskeskkonnad nagu gVisor ei toeta kõiki süsteemikutseid – sinu rakendus ei pruugi töötada. Üürnikupõhised Dockeri deemonid suurendavad mälukulu. Vali isoleerimistase, mis sobib sinu ohumudeliga: usaldusväärsete üürnike puhul võivad vaikimisi nimeruumid piisata; avaliku SaaS-i puhul investeeri käituskeskkonna liivakastidesse ja Kubernetes'i poliitikatesse. Testi põhjalikult enne tootmisesse viimist.

Kokkuvõte

Tõeline mitmeüürniku isoleerimine Dockeris on saavutatav, kui kihistada mitu kerneli funktsiooni, käituskeskkonna liivakaste ja orkestreerimiskontrolle. Alusta kasutajanimeruumidest ja seccomp'ist, siis liigu edasi üürnikupõhiste deemonite või liivakastimise käituskeskkondade juurde. Suuremahuliseks pakub Kubernetes poliitikapõhist isoleerimist. Kombineeri alati hüperviisori tasemel eraldatud hostiga maineka pakkuja juures. Ükski tehnika pole kuulikindel, kuid nende kombineerimine loob tugeva kaitse. Su üürnikud tänavad sind – ja seda teeb ka sinu turvaaudit.