Postizanje istinske izolacije za više stanara u Dockeru

Sažetak

Docker kontejneri dijele host kernel, što može biti sigurnosni problem za okruženja s više stanara 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 demone po stanaru, koristiti alate za pješčane kutije poput gVisor ili Firecracker za jaču izolaciju i orkestrirati s Kubernetesom za više stanara. Također ćemo pokriti odabir pravog infrastrukturnog provajdera koji nudi KVM-based virtualizaciju za dodatni sloj razdvajanja. Na kraju ćete imati plan za sigurno izvođenje radnih opterećenja s više stanara uz Docker.

Kada hostirate više stanara na jednom Docker hostu, zadana izolacija kontejnera—izgrađena na Linux imenskim prostorima i cgroups—često nije dovoljna. Bijeg iz kontejnera u jednom stanaru mogao bi ugroziti cijeli host i sve ostale kontejnere. Ovaj problem je posebno izražen u dijeljenom hostingu, SaaS platformama ili bilo kojem scenariju gdje se nepouzdani kod izvodi pored vašeg. Dobra vijest: možete složiti više tehnika izolacije da biste izgradili ojačano okruženje za više stanara. Ovaj vodič prolazi kroz šest praktičnih koraka, od jednostavnih mjera poput korisničkih imenskih prostora do naprednih mjera poput izvođenja u pješčanim kutijama i izbora infrastrukture.

Razumijevanje Dockerove zadane izolacije

Docker koristi Linux imenske prostore za izolaciju procesa, mreže, datotečnog sistema i drugih resursa. Cgroups ograničavaju CPU, memoriju i I/O. Ali oni dijele jedan kernel—ranjivost u kernelu može utjecati na sve kontejnere. Za pravi rad s više stanara, posebno s nepouzdanim stanarima, potrebna vam je odbrana u dubini. Kao što je diskutovano u Dizajniranje arhitekture Dockera s više stanara: odabir pravog nivoa izolacije, nivoi izolacije se kreću od slabih (samo imenski prostori) do jakih (hardverski virtualizirani). Krenimo od najslabijih.

Korak 1: Omogućite korisničke imenske prostore

Podrazumijevano, root unutar kontejnera mapira se na root na hostu. Bijeg iz kontejnera daje potpuni pristup hostu. Korisnički imenski prostori preslikavaju root kontejnera u non-root korisnika izvana. 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 nivou hosta (npr. montiranje datotečnih sistema) mogu se pokvariti. Za Drupal ili WordPress sajtove, obično je sigurno.

Korak 2: Primijenite Seccomp i AppArmor profile

Seccomp ograničava sistemske pozive koje kontejner može napraviti. Docker dolazi sa zadanim seccomp profilom koji blokira opasne syscall-ove poput mount i reboot. Za više stanara, dodatno ga pooštrite—blokirajte neuobičajene syscall-ove koje alati za bijeg koriste. Slično, AppArmor može ograničiti procese kontejnera. Kreirajte prilagođeni AppArmor profil koji zabranjuje pisanje u kernel interfejse i ograničava putanje datoteka. Oba se postavljaju putem --security-opt zastavica. Kombinujte ih za slojevitu odbranu.

Korak 3: Koristite Docker demone po stanaru

Pokretanje jednog Docker demona za sve stanare je rizično—svaki bijeg iz kontejnera mogao bi pristupiti utičnici demona. Izolujte demone po stanaru koristeći Docker-in-Docker (DinD) ili udaljene krajnje tač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 funkciju s korisničkim imenskim prostorima. Za orkestraciju, Kubernetes izolacija zasnovana na imenskim prostorima je praktičnija, kao što je pokriveno u Odbrana protiv bijega iz kontejnera: Praktični vodič za Docker izolaciju za hosting s više stanara.

Korak 4: Razmotrite izvođenja u pješčanim kutijama

Kada je sam Linux kernel nepouzdan, koristite izvođenje u pješčanoj kutiji koje dodaje lagani VM sloj. gVisor (runsc) presreće syscall-ove i implementira vlastiti kernel, dok Firecracker koristi mikro-VM-ove s hardverskom virtualizacijom. Oba se integrišu 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% niže, ali izolacija je znatno jača. Idealno za visokosigurnosne postavke s više stanara.

Korak 5: Orkestrirajte s Kubernetesom i sigurnosnim politikama

Kubernetes pruža izvornu podršku za više stanara kroz imenske prostore, Pod Security Standards i NetworkPolicies. Definišite imenske prostore po stanaru s kvotama resursa i nametnite ograničene sigurnosne kontekste podova (uklonite sve mogućnosti, read-only root datotečni sistem). Kontroleri prijema poput OPA/Gatekeeper mogu blokirati pogrešne konfiguracije. Ako upravljate s mnogo stanara, Kubernetes automatizira provođenje izolacije. Za orkestraciju na produkcijskoj skali, pogledajte Beyond Docker Compose: Orkestriranje kontejneriziranih aplikacija spremnih za produkciju.

Korak 6: Odaberite pravog hosting provajdera

Hipervizor vašeg infrastrukturnog provajdera je važan. Docker na dijeljenom hostingu (OpenVZ) daje slabu izolaciju—jedan stanar može vidjeti procese drugih. Radije birajte provajdere koji koriste KVM ili VMware, koji nude razdvajanje na nivou hardvera. Provajderi poput DigitalOcean, Kamatera ili AWS nude KVM-based VPS s namjenskim resursima. Za bare-metal, osigurajte da je BIOS-level virtualizacija omogućena za ugniježđene kontejnere. Provajder koji izoluje stanare na nivou hipervizora nadopunjuje vašu izolaciju kontejnera. Kao što je detaljno opisano u Ovladavanje Docker izolacijom za siguran i efikasan web hosting, host OS također treba biti ojačan s minimalnom površinom napada.

Upozorenja i kompromisi

Svaki dodatni sloj dodaje složenost i trošak performansi. Korisnički imenski prostori mogu pokvariti host-mount volume. Seccomp profili zahtijevaju podešavanje po aplikaciji. Izvođenja u pješčanim kutijama poput gVisor ne podržavaju sve syscall-ove—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, uložite u runtime pješčane kutije i Kubernetes politike. Testirajte temeljito prije produkcije.

Zaključak

Istinska izolacija za više stanara u Dockeru je ostvariva slojevanjem više kernel funkcija, runtime pješčanih kutija i orkestracijskih kontrola. Počnite s korisničkim imenskim prostorima i seccomp-om, zatim pređite na demone po stanaru ili runtime pješčane kutije. Za velike razmjere, Kubernetes pruža politički vođenu izolaciju. Uvijek uparite s hostom razdvojenim na nivou hipervizora od renomiranog provajdera. Nijedna tehnika sama po sebi nije neranjiva, ali njihovom kombinacijom stvarate snažnu odbranu. Vaši stanari će vam biti zahvalni—a i vaša sigurnosna revizija.