Multi-Tenancy auf Kubernetes: Strategien für saubere Tenant-Isolation

Wer Software-as-a-Service (SaaS) oder komplexe eCommerce-Lösungen betreibt, steht vor einer wirtschaftlichen und architektonischen Zerreißprobe: Die Kostenstruktur verlangt nach geteilter Infrastruktur (Multi-Tenancy), während Compliance und Stabilität eine strikte Trennung der Kunden (Isolation) fordern.

In einer Standard-Kubernetes-Installation ist “Isolation” jedoch ein dehnbarer Begriff. Ohne explizite Konfiguration ist ein Cluster ein “flaches” Netzwerk, in dem jeder mit jedem kommunizieren und theoretisch Ressourcen des Nachbarn stehlen kann. Um eine Enterprise-Grade Multi-Tenancy zu erreichen, müssen wir tief in die Abstraktionsebenen von Kubernetes eingreifen.

1. Die logische Ebene: Namespaces und Advanced RBAC

Der Namespace ist die primäre Gruppierungseinheit. Doch für echte Mandantentrennung reicht das bloße Anlegen nicht aus. Wir müssen den Zugriff über Role-Based Access Control (RBAC) auf Granularitätsebene steuern.

• ClusterRole vs. Role: Mandanten erhalten niemals ClusterRoles. Wir nutzen RoleBindings, die streng auf den jeweiligen Namespace begrenzt sind.
• Service Account Isolation: Jeder Tenant-Workload läuft unter einem dedizierten Service Account mit dem “Principle of Least Privilege”. Das verhindert, dass eine kompromittierte Applikation die Kubernetes-API abfragt, um Informationen über andere Namespaces zu erhalten.

2. Ressourcen-Governance: “Noisy Neighbors” technisch unterbinden

Das größte Risiko in geteilten Clustern ist der Ressourcen-Hunger einzelner Instanzen. Ohne Deckelung kann ein Speicherleck in der Applikation von Kunde A den gesamten Node in einen Out-of-Memory (OOM) Score treiben, der auch Kunde B mit in den Abgrund reißt.

ResourceQuotas & LimitRanges

Wir implementieren ein zweistufiges Sicherungssystem:

1. ResourceQuotas: Diese setzen ein hartes Limit für den gesamten Namespace (z.B. maximal 10 CPU-Cores und 32GB RAM über alle Pods hinweg). Wird das Limit erreicht, verweigert der API-Server die Skalierung weiterer Pods.
2. LimitRanges: Hiermit erzwingen wir Standardwerte für jeden einzelnen Container. Ein Entwickler kann keinen Pod starten, der keine requests und limits definiert. Das zwingt die Applikation in ein vorhersagbares Korsett und ermöglicht dem Scheduler (kube-scheduler), Workloads effizient und fair auf die Nodes zu verteilen.

Priority Classes

In kritischen eCommerce-Szenarien nutzen wir PriorityClasses. So können wir sicherstellen, dass “Premium-Tenants” oder systemkritische Dienste (wie das Ingress-Gateway) im Falle einer Ressourcenknappheit weniger wichtige Hintergrund-Jobs (wie Reporting-Worker) verdrängen dürfen.

3. Network Isolation: Zero-Trust im Cluster-Netzwerk

Standardmäßig ist das Pod-Netzwerk nicht segmentiert. Ein Angreifer, der in den Pod von Kunde A eindringt, könnte mittels Port-Scanning die Datenbank von Kunde B im Nachbar-Namespace finden.

Network Policies (L3/L4 Isolation)

Wir setzen ein Default-Deny-Prinzip um. Jedes Projekt startet mit einer Policy, die jeglichen ein- und ausgehenden Traffic verbietet. Erst explizite Regeln erlauben:

• Kommunikation zwischen Frontend und Backend innerhalb des Namespace.
• Zugriff auf globale Dienste (DNS, Ingress Controller).
• Abgeschirmte Pfade zu externen Datenbanken.

Service Mesh (L7 Isolation)

Für “Hard Multi-Tenancy” reicht L4 oft nicht aus. Durch den Einsatz eines Service Mesh (wie Istio oder Linkerd) implementieren wir mTLS (mutual TLS) zwischen den Pods. Damit ist nicht nur der Traffic verschlüsselt, sondern jeder Pod muss sich kryptografisch gegenüber seinem Kommunikationspartner ausweisen.

4. Storage-Isolation: Persistent Volume Claims (PVC)

Beim Speicherzugriff müssen wir verhindern, dass Mandanten durch Manipulation von Volume-IDs auf fremde Daten zugreifen.

• Dynamic Provisioning: Über das CSI (Container Storage Interface) stellen wir sicher, dass für jeden PVC ein eindeutiges, isoliertes Volume auf dem Storage-Backend (z.B. CEPH oder Cloud-Block-Storage) erstellt wird.
• StorageClasses: Durch separate StorageClasses für verschiedene Tenants können wir unterschiedliche Performance-Tiering und Verschlüsselungs-Keys (Encryption at Rest) erzwingen.

5. Runtime Security & Sandboxing

Für maximale Sicherheit (Hard Multi-Tenancy) betrachten wir den Container-Kernel als Angriffsvektor. Wenn alle Container denselben Host-Kernel teilen, könnte ein Kernel-Exploit die Isolation durchbrechen.

• RuntimeClasses: Wir nutzen Technologien wie gVisor oder Kata Containers, um Workloads in einer leichtgewichtigen Sandbox zu isolieren. Der Mandant läuft dann in einem eigenen, isolierten Kernel-Proxy, was das Risiko von “Container Escapes” gegen Null senkt.

Fazit: Die Plattform als Festung

Multi-Tenancy auf Kubernetes ist kein binärer Zustand, sondern ein Spektrum. Während für interne Teams oft eine “Soft Isolation” reicht, benötigen SaaS-Anbieter eine gehärtete Infrastruktur. Durch die Kombination von Namespaces, Quotas, Network Policies und Runtime Sandboxing verwandelt ayedo Kubernetes in eine mandantenfähige Hochleistungsplattform, die Skaleneffekte nutzt, ohne die Sicherheit zu opfern.

Haben Sie Fragen zur technischen Umsetzung von Network Policies oder zur Performance-Optimierung Ihrer Multi-Tenant-Umgebung? Unsere Experten unterstützen Sie bei der Architektur-Review.

FAQ

Warum ist ein CNI-Plugin für Multi-Tenancy entscheidend? Das CNI (Container Network Interface) ist für die Durchsetzung von Network Policies verantwortlich. Plugins wie Cilium nutzen eBPF, um hocheffiziente Isolation auf Kernel-Ebene zu bieten, ohne die Latenz klassischer iptables-Regeln.

Wie verhindert man “Pod Priority Preemption” Missbrauch? In Multi-Tenant Umgebungen sollten Nutzer nicht ihre eigenen PriorityClasses erstellen dürfen. Administratoren definieren feste Klassen, und über ein Admission Controller (wie OPA Gatekeeper) wird sichergestellt, dass Tenants nur die für sie vorgesehenen Prioritäten nutzen.

Was ist die Rolle von OPA (Open Policy Agent) Gatekeeper? Gatekeeper fungiert als “Türsteher”. Er prüft jedes Manifest gegen vordefinierte Policies (z.B. “Jeder Container muss ein ReadOnlyRootFilesystem haben”), bevor es vom API-Server akzeptiert wird. Dies ist essenziell für die Governance in Multi-Tenant Clustern.

Welchen Einfluss hat Multi-Tenancy auf das Logging? In einer Multi-Tenant Umgebung muss das Logging-System (z.B. VictoriaLogs oder Grafana Loki) in der Lage sein, Logs anhand der namespace_id oder tenant_id sicher zu trennen, damit Kunden über ein Dashboard nur ihre eigenen Log-Daten einsehen können.