Postizanje istinske višetenantske izolacije u Dockeru

Sažetak

Docker kontejneri dijele kernel domaćina, što može biti sigurnosni problem za višetenantska okruženja gdje stanari možda ne vjeruju jedni drugima. Ovaj članak objašnjava praznine u izolaciji u zadanim Docker postavkama i pruža konkretne korake za jačanje izolacije korištenjem Linux imenskih prostora, cgroups, korisničkih imenskih prostora, seccomp-a, AppArmor-a i hardverske virtualizacije. Naučit ćete kako konfigurirati Docker demon po stanaru, koristiti alate za sandboxing poput gVisor ili Firecracker za jaču izolaciju te orkestrirati s Kubernetesom za višetenantsku podršku. Također ćemo pokriti odabir pravog pružatelja infrastrukture koji nudi KVM-baziranu virtualizaciju za dodatni sloj odvajanja. Na kraju ćete imati nacrt za sigurno izvođenje višetenantskih radnih opterećenja s Dockerom.

Kada hostirate više stanara na jednom Docker domaćinu, zadana izolacija kontejnera – izgrađena na Linux imenskim prostorima i cgroups – često nije dovoljna. Bijeg iz kontejnera kod jednog stanara mogao bi ugroziti cijeli domaćin i sve ostale kontejnere. Ovaj problem je posebno izražen u shared hosting-u, SaaS platformama ili bilo kojem scenariju gdje se nepovjerljivi kod izvodi uz vaš vlastiti. Dobra vijest: možete složiti više tehnika izolacije kako biste izgradili otvrdnuto višetenantsko okruženje. Ovaj vodič prolazi kroz šest praktičnih koraka, od niskih grana poput korisničkih imenskih prostora do naprednih mjera poput sandboxiranih runtime-ova i odabira infrastrukture.

Razumijevanje Dockerove zadane izolacije

Docker koristi Linux imenske prostore za izolaciju procesa, mreže, datotečnog sustava i drugih resursa. Cgroups ograničavaju CPU, memoriju i I/O. No, oni dijele jedan kernel – ranjivost u kernelu može utjecati na sve kontejnere. Za istinsku višetenantsku podršku, posebno s nepovjerljivim stanarima, potrebna vam je dubinska obrana. Kao što je objašnjeno u Dizajniranje višetenantske Docker arhitekture: Odabir pravog nivoa izolacije, nivoi izolacije kreću se od slabih (samo imenski prostori) do jakih (hardverska virtualizacija). Gradimo od najslabijeg.

Korak 1: Omogućite korisničke imenske prostore

Prema zadanim postavkama, root unutar kontejnera mapira se na root na domaćinu. Bijeg iz kontejnera daje potpuni pristup domaćinu. Korisnički imenski prostori premapiraju root kontejnera u ne-root korisnika izvan. Omogućite ga globalno s dockerd --userns-remap=default ili po kontejneru s --userns=host. Ovaj jednostavan korak eliminira mnoge napade eskalacije privilegija. Testirajte svoje aplikacije: neke koje zahtijevaju privilegije na razini domaćina (npr. montiranje datotečnih sustava) mogu se pokvariti. Za Drupal ili WordPress stranice, obično je sigurno.

Korak 2: Primijenite Seccomp i AppArmor profile

Seccomp ograničava sistemske pozive koje kontejner može napraviti. Docker dolazi s zadanim seccomp profilom koji blokira opasne syscall-e poput mount i reboot. Za višetenantsko okruženje, dodatno ga zategnite – blokirajte neuobičajene syscall-e koje alati za bijeg koriste. Slično, AppArmor može ograničiti procese kontejnera. Izradite prilagođeni AppArmor profil koji zabranjuje pisanje u kernel sučelja i ograničava putanje datoteka. Oba se postavljaju putem --security-opt zastavica. Kombinirajte ih za slojevitu obranu.

Korak 3: Koristite Docker demone po stanaru

Pokretanje jednog Docker demona za sve stanare je rizično – bilo koji bijeg iz kontejnera mogao bi pristupiti utičnici demona. Izolirajte demone po stanaru koristeći Docker-in-Docker (DinD) ili udaljene krajnje točke demona. Na primjer, pokrenite Docker demon unutar kontejnera s --privileged (ali to slabi izolaciju). Bolji pristup: pokrenite zasebne demone na zasebnim VM-ovima ili koristite Dockerovu eksperimentalnu --group značajku s korisničkim imenskim prostorima. Za orkestraciju, Kubernetes izolacija temeljena na imenskim prostorima je praktičnija, kao što je objašnjeno u Obrana protiv bijega iz kontejnera: Praktični vodič za Docker izolaciju za višetenantski hosting.

Korak 4: Razmislite o sandboxiranim runtime-ovima

Kada je sam Linux kernel nepovjerljiv, koristite sandboxirani runtime koji dodaje lagani VM sloj. gVisor (runsc) presreće syscall-e i implementira vlastiti kernel, dok Firecracker koristi mikro-VM-ove s hardverskom virtualizacijom. Oba se integriraju s Dockerom putem containerd runtime-ova. Na primjer, dodajte "runtimes": {"runsc": {}} u Docker demon konfiguraciju i pokrenite kontejnere s --runtime=runsc. Performanse su 5–15% slabije, ali izolacija je znatno jača. Idealno za visokosigurnosne višetenantske postavke.

Korak 5: Orkestrirajte s Kubernetesom i sigurnosnim politikama

Kubernetes pruža izvornu višetenantsku podršku kroz imenske prostore, Pod sigurnosne standarde i NetworkPolicies. Definirajte imenske prostore po stanaru s kvotama resursa i primijenite ograničene sigurnosne kontekste podova (odustanite od svih mogućnosti, samo za čitanje root datotečni sustav). Admission kontroleri poput OPA/Gatekeeper mogu blokirati pogrešne konfiguracije. Ako upravljate s mnogo stanara, Kubernetes automatizira provedbu izolacije. Za orkestraciju na produkcijskoj razini, pogledajte Beyond Docker Compose: Orkestriranje produkcijski spremnih kontejneriziranih aplikacija.

Korak 6: Odaberite pravog pružatelja hostinga

Hipervizor vašeg pružatelja infrastrukture je važan. Docker na shared hosting-u (OpenVZ) daje slabu izolaciju – jedan stanar može vidjeti druge procese. Preferirajte pružatelje koji koriste KVM ili VMware, koji nude odvajanje na razini hardvera. Pružatelji poput DigitalOcean, Kamatera ili AWS nude KVM-bazirane VPS-ove s namjenskim resursima. Za bare-metal, osigurajte da je virtualizacija na BIOS razini omogućena za ugniježđene kontejnere. Pružatelj koji izolira stanare na razini hipervizora nadopunjuje vašu izolaciju kontejnera. Kao što je detaljno opisano u Ovladavanje Docker izolacijom za siguran i učinkovit web hosting, host OS također treba biti otvrdnut s minimalnom površinom napada.

Ograničenja i kompromisi

Svaki dodatni sloj dodaje složenost i trošak performansi. Korisnički imenski prostori mogu pokvariti volumene montirane na domaćinu. Seccomp profile zahtijevaju prilagodbu po aplikaciji. Sandboxirani runtime-ovi poput gVisor ne podržavaju sve syscall-e – vaša aplikacija možda neće raditi. Docker demoni po stanaru povećavaju memorijski overhead. Odaberite nivo izolacije koji odgovara vašem modelu prijetnje: za pouzdane stanare, zadani imenski prostori mogu biti dovoljni; za javni SaaS, investirajte u runtime sandboxove i Kubernetes politike. Temeljito testirajte prije produkcije.

Zaključak

Istinska višetenantska izolacija u Dockeru je ostvariva slojevanjem više kernel značajki, runtime sandboxova i orkestracijskih kontrola. Počnite s korisničkim imenskim prostorima i seccomp-om, zatim napredujte do demona po stanaru ili sandboxiranih runtime-ova. Za velike razmjere, Kubernetes pruža izolaciju vođenu politikama. Uvijek uparite s hipervizorom odvojenim domaćinom od renomiranog pružatelja. Niti jedna tehnika nije neprobojna, ali njihovom kombinacijom stvarate snažnu obranu. Vaši stanari će vam biti zahvalni – i vaša sigurnosna revizija također.