Het ontwerpen van een multi-tenant Docker-architectuur: het kiezen van het juiste isolatieniveau

Samenvatting

Multi-tenant Docker-hosting vereist een balans tussen kosten, complexiteit en isolatie. Gedeelde containers zijn goedkoop, maar riskeren container escape; aparte stacks per tenant bieden sterke isolatie tegen hogere kosten. Dit artikel bespreekt drie veelvoorkomende architecturen: enkele Docker-daemon met namespaces, Docker-in-Docker per tenant, en aparte VM's per tenant. Je leert hoe je de vereisten van je tenants kunt beoordelen, resource-limieten kunt implementeren en read-only filesystems kunt gebruiken om containers te versterken. We behandelen ook orchestratietools zoals Kubernetes en Docker Swarm om multi-tenant implementaties te beheren. Aan het einde heb je een beslissingskader om het juiste isolatieniveau voor jouw use case te kiezen. Kanttekeningen zijn onder andere prestatie-overhead en operationele complexiteit. Conclusie: gedeelde kernel-isolatie is acceptabel voor laag-risico tenants, maar sterke isolatie (geen gedeelde kernel) is essentieel voor gevoelige workloads.

Wanneer je een multi-tenant SaaS-platform op Docker draait, is de grootste architectuurbeslissing hoeveel isolatie je tussen tenants wilt afdwingen. Te weinig, en een enkele gecompromitteerde container kan gegevens lekken over je hele klantenbestand. Te veel, en je teniet de kosten- en operationele voordelen die containers beloofden.

Dit artikel biedt je een praktisch beslissingskader: beoordeel het vertrouwensniveau van je tenants, kies een isolatie-architectuur, versterk je containers en orchestreer op schaal. Je gaat weg met een concrete set afwegingen en een stappenplan om veilig te implementeren.

Stap 1: Beoordeel Tenant Vertrouwen en Gevoeligheid

Niet alle tenants zijn gelijk. Gebruikers van het gratis niveau kunnen tevreden zijn met gedeelde infrastructuur, terwijl zakelijke klanten sterke garanties eisen. Classificeer tenants in drie niveaus:

• Laag vertrouwen (bijv. anonieme proefgebruikers): minimale isolatie acceptabel, hoogste risico op misbruik.
• Gemiddeld vertrouwen (bijv. geverifieerde klanten): matige isolatie nodig om accidentele interferentie te voorkomen.
• Hoog vertrouwen (bijv. getekende contracten met SLA's): sterke isolatie vereist – mogelijk aparte VM's.

Overweeg ook gegevensgevoeligheid: als tenants PII of financiële gegevens opslaan, neig dan naar sterkere isolatie. Deze classificatie stuurt elk volgend besluit.

Stap 2: Kies Je Isolatie-architectuur

Optie A: Gedeelde Docker Daemon met Linux Namespaces (Goedkoopst, Zwakste Isolatie)

Alle tenants draaien als containers op dezelfde host en dezelfde Docker daemon. Isolatie vertrouwt volledig op kernel namespaces en cgroups. Dit is het standaard Docker-model.

Voordelen: Laagste overhead, makkelijk te beheren, geen extra tools nodig. Geweldig voor interne tools of niet-kritische multi-tenancy.

Nadelen: Een kernel-kwetsbaarheid kan de isolatie doorbreken. Een kwaadwillende tenant kan proberen te ontsnappen uit de container. Resource-contention is echt – een luidruchtige buur kan anderen uithongeren.

Wanneer te gebruiken: Laag-vertrouwen tenants met vluchtige gegevens, bijv. demo-omgevingen of CI/CD-runners.

Optie B: Docker-in-Docker per Tenant (Matige Isolatie, Gematigde Kosten)

Elke tenant krijgt zijn eigen Docker daemon in een container (Docker-in-Docker – DinD). Dit biedt een aparte containerlevenscyclus en voorkomt dat de ene tenant de containers van een andere ziet.

Voordelen: Betere isolatie dan gedeelde daemon; elke tenant kan zijn eigen Docker Compose-stack draaien. Nuttig wanneer tenants hun eigen containers moeten bouwen en beheren.

Nadelen: DinD heeft bekende valkuilen – geneste storage drivers kunnen problemen veroorzaken, en je deelt nog steeds de host-kernel. Prestatie-overhead kan 10-20% zijn door geneste lagen. Beveiliging is niet perfect; een container-ontsnapping uit de DinD-container leidt nog steeds naar de host.

Wanneer te gebruiken: Gemiddeld-vertrouwen tenants die hun eigen services moeten samenstellen, bijv. een platform waarmee gebruikers aangepaste web-apps kunnen implementeren.

Optie C: Aparte VM's per Tenant (Sterkste Isolatie, Hoogste Kosten)

Elke tenant draait op een toegewijde virtuele machine, met Docker in die VM. De hypervisor biedt hardware-level isolatie – geen kernel delen.

Voordelen: Sterkste isolatie – container-ontsnapping leidt alleen naar de VM, niet naar andere tenants. Voldoet aan compliance-eisen zoals PCI-DSS en HIPAA. Prestatie-isolatie is bijna absoluut.

Nadelen: Hoge overhead (volledig OS per tenant), langzamere provisioning, meer beheercomplexiteit. Je verliest de dichtheidsvoordelen van containers.

Wanneer te gebruiken: Hoog-vertrouwen tenants met gevoelige gegevens, of elke tenant waar een inbreuk catastrofaal zou zijn.

Stap 3: Versterk Containers in Alle Architecturen

Welke architectuur je ook kiest, pas deze beveiligingspraktijken universeel toe:

• Gebruik vertrouwde, minimale basisimages (bijv. Alpine, distroless) om het aanvalsoppervlak te verkleinen.
• Draai containers als niet-root – draai nooit als root in de container. Stel USER in je Dockerfile in.
• Schakel read-only root filesystem in in de container-specificatie; mount schrijfbare mappen alleen voor gegevens.
• Stel resource-limieten in met --memory, --cpus om problemen met luidruchtige buren te voorkomen.
• Beperk netwerken: gebruik door de gebruiker gedefinieerde bridge-netwerken en stel alleen noodzakelijke poorten bloot.

Voor multi-tenant scenario's, implementeer ook:

• Per-tenant API-rate limiting bij de gateway.
• Audit-logging van alle containeracties.

Voor een diepere duik in het voorkomen van container-ontsnapping, zie onze gids over Verdedigen tegen container escape.

Stap 4: Orkestreer Multi-Tenant Deployments

Handmatig beheer van veel containers wordt snel onbeheersbaar. Gebruik een orchestrator:

• Docker Swarm is het eenvoudigst: native Docker-integratie, ingebouwde load balancing en geheimenbeheer. Ideaal voor kleine tot middelgrote implementaties. Je kunt de stack van elke tenant op toegewijde knooppunten plaatsen met behulp van labels en constraints.
• Kubernetes biedt meer geavanceerde isolatie via namespaces, NetworkPolicies en PodSecurityPolicies. Het voegt echter aanzienlijke complexiteit toe. Overweeg beheerde Kubernetes (GKE, EKS) om de operationele last te verminderen.
• HashiCorp Nomad is een lichter alternatief dat Docker en niet-container workloads ondersteunt.

Voor een productieklare orchestratie-opstelling, lees Beyond Docker Compose: Orchestrating Production-Ready Containerized Applications.

Kanttekeningen en Afwegingen

• Prestatie-overhead: DinD kan 10-15% CPU/geheugen overhead toevoegen. VM's voegen 5-10% toe vs. bare-metal maar meer dan containers. Test onder realistische belasting.
• Operationele complexiteit: Aparte VM's vereisen het beheren van OS-updates, hypervisor-patches en VM-levenscycli. DinD introduceert problemen met storage drivers (overlay2 in overlay2 wordt niet ondersteund; gebruik --storage-driver vfs maar het is traag).
• Compliance: Als je PCI-DSS nodig hebt, worden gedeelde kernel-architecturen over het algemeen niet geaccepteerd. Gebruik VM's met goede segmentatie.
• Kosten: Gedeelde Docker daemon kost bijna niets extra. DinD kost iets meer CPU/geheugen. VM's kunnen 2-5x duurder zijn per tenant vanwege licenties en resources.

Conclusie: Jouw Beslissingskader

| Vertrouwensniveau | Aanbevolen Architectuur | Belangrijkste Kanttekeningen | |-------------------|-------------------------|------------------------------| | Laag | Gedeelde Docker daemon | Accepteer container-ontsnappingsrisico; implementeer rate limiting en auditing. | | Gemiddeld | DinD per tenant | Behandel geneste storage; overweeg beveiligingsgroepen per tenant. | | Hoog | Aparte VM's met Docker | Budgetteer voor extra compute; automatiseer VM-provisioning (bijv. Terraform). |

Voor veel SaaS-bedrijven werkt een hybride aanpak: gebruik gedeelde daemon voor gratis niveaus, DinD voor betalende klanten en VM's voor zakelijke klanten. Dit geeft je kostenefficiëntie waar het risico laag is en sterke isolatie waar het ertoe doet.

Onthoud: isolatie is een spectrum, geen binaire keuze. Het doel is om het beschermingsniveau af te stemmen op de waarde van de gegevens en de betrouwbaarheid van de tenant. Begin met de eenvoudigste optie die aan je beveiligingseisen voldoet en evolueer daarna indien nodig.

Voor aanvullende best practices over het beveiligen van containerconfiguraties, zie Het beveiligen van je webapplicaties met Docker: een praktische gids voor isolatie en best practices.