Die Festung im Cluster:

In vielen wachsenden Plattform- und eCommerce-Architekturen gilt Kubernetes als De-facto-Standard für Skalierung und Ausfallsicherheit. Doch sobald mehrere Mandanten auf einer gemeinsamen Infrastruktur betrieben werden, zeigt sich die Standardkonfiguration von Kubernetes von ihrer verwundbaren Seite: Namespaces bieten standardmäßig nur eine logische Gruppierung, aber keinerlei verlässliche Isolation auf Netzwerk-, CPU- oder Memory-Ebene.

Hard Multi-Tenancy schließt diese Lücke. Durch die Kombination aus kompromissloser Namespace-Härtung, strikten NetworkPolicies im Default-Deny-Modus und präziser Ressourcen-Gegensteuerung über cgroups v2 und PriorityClasses entsteht eine mandantenfähige Plattform, die maximale Kosteneffizienz im Shared-Cluster-Modell mit der Sicherheit physisch getrennter Server vereint.

Das Problem: Die trügerische Sicherheit von Standard-Namespaces

Ohne tiefgreifende Härtung führt der Betrieb mehrerer Mandanten auf einem Shared Cluster unweigerlich zu Sicherheitsrisiken und unkalkulierbaren Performance-Einbrüchen. Der Glaube, Namespaces seien isolierte Sicherheitsgrenzen, ist ein gefährlicher Trugschluss.

1. Das Flat-Network-Sicherheitsrisiko

Im Standardzustand eines Kubernetes-Clusters darf jeder Pod mit jedem anderen Pod über Namespace-Grenzen hinweg uneingeschränkt auf Layer-3- und Layer-4-Ebene kommunizieren. Kompromittiert ein Angreifer eine einzige Kundeninstanz über eine Web-Schwachstelle, steht ihm das gesamte interne Overlay-Netzwerk für Lateral Movement und unbefugte Zugriffe auf Nachbarmandanten offen.

2. Der Noisy-Neighbor-Effekt

Wenn ein Mandant unvorhergesehene Lastspitzen erfährt – etwa durch Marketing-Aktionen, fehlerhafte Batch-Jobs oder DDoS-Traffic –, konkurrieren seine Pods unkontrolliert um Shared Resources auf den Worker-Nodes. Ohne strikte Limits entzieht dieser eine Mandant den Nachbarinstanzen CPU-Zyklen und RAM, was zu Latenzspitzen, Timeouts und Kaskadeneffekten (OOMKills) im gesamten Cluster führt.

3. Ungeregelter Zugriff auf Control-Plane-Ressourcen

Ohne feingliedrige ResourceQuotas kann ein einzelner Mandant durch fehlerhafte Deployment-Schleifen oder exzessive Objekterstellung den Kubernetes API-Server und das etcd-Backend überlasten. Dies beeinträchtigt nicht nur die eigene Instanz, sondern lähmt die gesamte Control Plane für alle anderen Mandanten und Plattform-Dienste.

Die Lösung: Das Drei-Säulen-Modell für Hard Multi-Tenancy

ayedo etabliert Hard Multi-Tenancy nicht als nachträgliche Konfigurationsdisziplin, sondern als deklaratives Plattform-Fundament. Die Isolation greift dabei synchron auf Netzwerk-, Compute- und API-Ebene.

1. Zero-Trust-Netzwerksegmentierung via Default-Deny

Jeder neu provisionierte Mandanten-Namespace erhält automatisiert eine Baseline-NetworkPolicy, die sämtlichen eingehenden und ausgehenden Datenverkehr (Ingress und Egress) standardmäßig blockiert. Erst dedizierte, signierte Policies öffnen gezielt Ports für den jeweiligen Ingress-Controller, interne Datenbanken und explizit autorisierte externe Endpunkte. Jegliche Cross-Namespace-Kommunikation wird auf CNI-Ebene via eBPF oder iptables deterministisch verworfen.

2. Deterministische Compute-Governance mit LimitRanges und cgroups v2

Um Ressourcen-Kannibalisierung auszuschließen, erzwingt die Plattform über Admission Webhooks zwingend die Definition von resources.requests und resources.limits. LimitRanges stellen sicher, dass Container ohne explizite Limits gar nicht erst gestartet werden dürfen. Das Kernel-Subsystem cgroups v2 sorgt dafür, dass CPU-Throttling granular greift und Memory-Limits bei Überschreitung isoliert nur den verursachenden Container terminieren (OOMKilled), ohne Nachbar-Workloads auf der Node zu gefährden.

3. API-Budgetierung und PriorityClasses

Über clusterweite ResourceQuotas wird die maximale Anzahl an Pods, Services, PersistentVolumeClaims und Secrets pro Mandant hart gedeckelt. Ergänzend weisen PriorityClasses geschäftskritischen Produktionsinstanzen höhere Scheduling-Prioritäten zu als Staging- oder Test-Workloads, wodurch Kubernetes bei Engpässen unkritische Pods gezielt verdrängt, um SLA-kritische Mandanten stabil zu halten.

Strategischer und wirtschaftlicher Mehrwert

• Dramatische TCO-Senkung gegenüber VM-Silos: Durch das Teilen der Kubernetes Control Plane und Worker-Nodes sinken die Infrastrukturkosten um 40% bis 60% im Vergleich zu dedizierten VM-Clustern pro Kunde, bei gleichwertiger Isolation.
• Vollständige NIS-2- und DORA-Konformität: Die lückenlose Netzwerkisolation und mandantenscharfe Zugriffskontrolle erfüllen die regulatorischen Vorgaben an Segmentierung, Zugriffsschutz und Ausfallsicherheit in kritischen Branchen.
• Auditierbare DSGVO-Mandantentrennung: Strikte Default-Deny-Netzwerkregeln garantieren, dass Datenströme zwischen Mandanten technisch unmöglich sind, was Compliance-Audits und Kunden-Zertifizierungen massiv beschleunigt.
• Souveräner Betrieb auf europäischer IaaS: Hard Multi-Tenancy läuft unabhängig von proprietären Hyperscaler-Features auf standardisierter Hardware bei europäischen Providern wie Hetzner oder IONOS – ohne Bindung an teure Cloud-spezifische IAM-Ökosysteme.

Fazit

Hard Multi-Tenancy beweist, dass maximale Ressourcendichte und kompromisslose Sicherheit kein Widerspruch sind, sondern das Ergebnis sauberer Plattform-Architektur. Wer Kubernetes über deklarative Policies und strikte Kernel-Ressourcenkontrolle absichert, schützt nicht nur sensible Kundendaten vor lateralen Bedrohungen, sondern skaliert sein Betriebsmodell mit berechenbaren Kosten und absoluter Verlässlichkeit.

Häufig gestellte Fragen (FAQ)

Reicht Hard Multi-Tenancy aus, um auch bösartigen Fremdcode sicher auszuführen?

Für Standard-SaaS- und eCommerce-Applikationen mit vertrauenswürdiger Codebasis bietet dieses Modell exzellenten Schutz. Müssen jedoch beliebige, ungetestete Fremdcodes oder User-Scripts ausgeführt werden, sollte die Plattform zusätzlich um Container -Sandboxing-Technologien wie gVisor oder Kata Containers (MicroVMs) auf Node-Ebene erweitert werden, um einen Kernel-Bruch abzusichern.

Führt das Durchsetzen harter CPU-Limits nicht zu unnötigem Performance-Verlust?

Nein, wenn CPU-Requests und CPU-Limits strategisch dimensioniert sind. Durch den Einsatz von cgroups v2 in modernen Linux-Kerneln arbeitet das CFS-Bandwidth-Quota-System extrem präzise. Workloads erhalten garantierte Mindest-Rechenzeit, während Lastspitzen innerhalb definierter Korridore abgefangen werden, ohne andere Mandanten zu verlangsamen.

Wie wird sichergestellt, dass Entwickler nicht versehentlich ungesicherte Namespaces deployen?

Dies wird durch GitOps in Kombination mit Kubernetes Admission Controllern (wie Kyverno oder OPA Gatekeeper) garantiert. Versucht eine Pipeline, ein Namespace-Manifest oder einen Pod ohne gültige NetworkPolicy, ResourceQuota oder LimitRange auszurollen, blockiert der Admission Controller den API-Aufruf bereits vor der Erstellung.