Opnå ægte multi-tenant isolering i Docker

Resumé

Docker-containere deler værtskernen, hvilket kan være en sikkerhedsbekymring for multi-tenant miljøer, hvor lejere måske ikke stoler på hinanden. Denne artikel forklarer isoleringshullerne i standard Docker-opsætninger og giver konkrete trin til at styrke isoleringen ved hjælp af Linux namespaces, cgroups, user namespaces, seccomp, AppArmor og hardwarevirtualisering. Du lærer, hvordan du konfigurerer per-tenant Docker-dæmoner, bruger sandboxing-værktøjer som gVisor eller Firecracker til stærkere isolering, og orkestrerer med Kubernetes til multi-tenancy. Vi dækker også valg af den rigtige infrastrukturudbyder, der tilbyder KVM-baseret virtualisering for et ekstra lag af adskillelse. Til sidst vil du have en plan for at køre sikre multi-tenant workloads med Docker.

Når du hoster flere lejere på en enkelt Docker-vært, er standard containerisolering—bygget på Linux namespaces og cgroups—ofte ikke nok. En container-flugt hos en lejer kan kompromittere hele værten og alle andre containere. Dette problem er især akut i delt hosting, SaaS-platforme eller ethvert scenario, hvor utroværdig kode kører side om side med din egen. Den gode nyhed: du kan stable flere isolationsteknikker for at opbygge et hærdet multi-tenant miljø. Denne guide gennemgår seks praktiske trin, fra lavthængende frugter som user namespaces til avancerede foranstaltninger som sandboxed runtimes og infrastrukturvalg.

Forståelse af Dockers standardisolering

Docker bruger Linux namespaces til at isolere processer, netværk, filsystem og andre ressourcer. Cgroups begrænser CPU, hukommelse og I/O. Men disse deler en enkelt kerne—en sårbarhed i kernen kan påvirke alle containere. For ægte multi-tenancy, især med utroværdige lejere, har du brug for forsvar i dybden. Som beskrevet i Design af en multi-tenant Docker-arkitektur: Valg af det rigtige isoleringsniveau spænder isoleringsniveauer fra svag (kun namespace) til stærk (hardwarevirtualiseret). Lad os bygge op fra den svageste.

Trin 1: Aktivér User Namespaces

Som standard er root inde i en container kortlagt til root på værten. En container-gennembrud giver fuld værtsadgang. User namespaces omkortlægger container-root til en ikke-root-bruger udenfor. Aktivér det globalt med dockerd --userns-remap=default eller per container med --userns=host. Dette enkle trin eliminerer mange privilegieeskalationsangreb. Test dine applikationer: nogle, der kræver vært-niveau privilegier (f.eks. montering af filsystemer), kan gå i stykker. For Drupal- eller WordPress-sites er det normalt sikkert.

Trin 2: Anvend Seccomp- og AppArmor-profiler

Seccomp begrænser de systemkald, en container kan foretage. Docker leveres med en standard seccomp-profil, der blokerer farlige syscalls som mount og reboot. For multi-tenant, stram den yderligere—bloker ualmindelige syscalls, som flugtværktøjer bruger. Tilsvarende kan AppArmor begrænse containerprocesser. Opret en brugerdefineret AppArmor-profil, der nægter skriveadgang til kernegrænseflader og begrænser filstier. Begge sættes via --security-opt flag. Kombiner dem for lagdelt forsvar.

Trin 3: Brug Per-Tenant Docker-dæmoner

At køre en enkelt Docker-dæmon for alle lejere er risikabelt—enhver container-flugt kan få adgang til dæmon-socket. Isolér dæmoner per lejer ved at bruge Docker-in-Docker (DinD) eller fjerndæmon-endepunkter. For eksempel kan du starte en Docker-dæmon inde i en container med --privileged (men det svækker isoleringen). En bedre tilgang: kør separate dæmoner på separate VM'er eller brug Dockers eksperimentelle --group funktion med user namespaces. Til orkestrering er Kubernetes namespace-baseret isolering mere praktisk, som beskrevet i Forsvar mod container-flugt: En praktisk guide til Docker-isolering til multi-tenant hosting.

Trin 4: Overvej Sandboxed Runtimes

Når selve Linux-kernen er utroværdig, brug et sandboxed runtime, der tilføjer et let VM-lag. gVisor (runsc) opsnapper syscalls og implementerer sin egen kerne, mens Firecracker bruger mikro-VM'er med hardwarevirtualisering. Begge integreres med Docker via containerd runtimes. For eksempel, tilføj "runtimes": {"runsc": {}} til Docker-dæmonkonfigurationen og kør containere med --runtime=runsc. Ydelsesomkostningerne er 5–15% men isoleringen er langt stærkere. Ideel til højsikkerheds multi-tenant opsætninger.

Trin 5: Orkestrér med Kubernetes og sikkerhedspolitikker

Kubernetes tilbyder indbygget multi-tenancy gennem namespaces, Pod Security Standards og NetworkPolicies. Definer per-tenant namespaces med ressourcekvoter, og håndhæv begrænsede pod-sikkerhedskontekster (fjern alle capabilities, skrivebeskyttet rod-filsystem). Adgangskontrollere som OPA/Gatekeeper kan blokere fejlkonfigurationer. Hvis du administrerer mange lejere, automatiserer Kubernetes isoleringshåndhævelse. Til produktionsskala orkestrering, se Beyond Docker Compose: Orkestrering af produktionsklare containeriserede applikationer.

Trin 6: Vælg den rigtige hostingudbyder

Din infrastrukturudbyders hypervisor betyder noget. Docker på delt hosting (OpenVZ) giver svag isolering—en lejer kan se andre processer. Foretræk udbydere, der bruger KVM eller VMware, som tilbyder hardware-niveau adskillelse. Udbydere som DigitalOcean, Kamatera eller AWS tilbyder KVM-baserede VPS med dedikerede ressourcer. For bare-metal, sørg for at BIOS-niveau virtualisering er aktiveret til nestede containere. En udbyder, der isolerer lejere på hypervisorlaget, supplerer din containerisolering. Som beskrevet i Mestring af Docker-isolering til sikker og effektiv webhosting, bør værts-OS også hærdes med minimal angrebsflade.

Forbehold og afvejninger

Hvert ekstra lag tilføjer kompleksitet og ydelsesomkostninger. User namespaces kan bryde værtsmonterede volumener. Seccomp-profiler kræver justering per applikation. Sandboxed runtimes som gVisor understøtter ikke alle syscalls—din app fungerer måske ikke. Per-tenant Docker-dæmoner øger hukommelsesoverhead. Vælg det isoleringsniveau, der passer til din trusselsmodel: for betroede lejere kan standard namespaces være tilstrækkeligt; for offentlig SaaS, invester i runtime-sandkasser og Kubernetes-politikker. Test grundigt før produktion.

Konklusion

Ægte multi-tenant isolering i Docker er opnåelig ved at lægge flere kernefunktioner, runtime-sandkasser og orkestreringskontroller i lag. Start med user namespaces og seccomp, gå derefter videre til per-tenant dæmoner eller sandboxed runtimes. Til store skalaer giver Kubernetes politikstyret isolering. Kombinér altid med en hypervisor-niveau adskilt vært fra en velrenommeret udbyder. Ingen enkelt teknik er uigennemtrængelig, men at kombinere dem skaber et robust forsvar. Dine lejere vil takke dig—og det vil din sikkerhedsrevision også.