Multi-Tenant-Kubernetes ohne Operations-Schmerz

Warum Multi-Tenancy auf Kubernetes anders ist als Single-Tenant

Kubernetes wurde ursprünglich für Single-Tenant-Workloads entworfen (Burns et al., „Borg, Omega, and Kubernetes", Communications of the ACM 2016) ^[1]. Die Multi-Tenant-Eigenschaften sind erst nachträglich entstanden — Namespaces, Network Policies, RBAC, Pod Security Standards. Das hat Konsequenzen für jeden, der eine Plattform betreibt, auf der mehrere Mandanten oder mehrere Klienten-Workloads laufen.

Wir betreiben Kubernetes-Plattformen für mehrere Tenants und mehrere Cloud-Sets parallel. Drei Prinzipien haben sich bewährt: deklarative Provisionierung, Secrets-Hygiene und GitOps. Das sind keine neuen Ideen, aber die Disziplin in der Kombination ist selten.

Prinzip 1: Deklarative Provisionierung mit Terragrunt

Erstens: ein klar deklarativer Provisionierungs-Pfad. Wir verwenden Terragrunt ^[2] als dünne Wrapper-Schicht über Terraform — ein File pro Cluster-Set, drei Phasen pro Cluster (Network, Cluster, Workload). Die Phase-Trennung ist nicht Geschmackssache: sie ermöglicht Rollbacks pro Schicht und vermeidet, dass ein fehlgeschlagener Workload-Apply einen ganzen Cluster neu provisionieren muss.

Konkret heißt das: ein neuer Cluster ist ein neues Verzeichnis mit drei `terragrunt.hcl`-Dateien, die auf gemeinsame Module verweisen. Variable Inputs (Region, Cluster-Größe, Tenant-Liste) liegen im Verzeichnis. Cluster-übergreifende Werte (Subnet-Pläne, IAM-Boundaries) liegen in einem zentralen Repo, das per Live-State referenziert wird.

Prinzip 2: Secrets ausschließlich über Vault

Zweitens: Secrets ausschließlich über HashiCorp Vault ^[3] — niemals im Terraform-State, niemals in Git. Das ist eine harte Regel mit zwei Konsequenzen: erstens müssen wir den Vault-Bootstrap selbst lösen (Auto-Unseal über Cloud KMS, root token im Break-Glass-Tresor); zweitens werden alle Workload-Credentials zur Laufzeit über Vault Agent oder External Secrets Operator ^[4] injiziert.

Die Sicherheits-Begründung ist Standard: ein State-File mit Secrets ist ein einzelner Punkt, der Backups, CI-Logs und Operator-Workstations kompromittiert. Die Operations-Begründung ist subtiler: nur dann lassen sich Secrets ohne Cluster-Touch rotieren, und nur dann hat ein Secret-Leak einen klar begrenzten Blast-Radius. Beides ist in NIST SP 800-57 Part 1 (Recommendation for Key Management) als Best Practice beschrieben ^[5].

Prinzip 3: GitOps mit ArgoCD

Drittens: GitOps mit ArgoCD ^[6] als Single-Source-of-Truth für alle Add-ons. Day-2 wird zur Last, sobald Provisionierung und Konfiguration in unterschiedlichen Repos leben oder per Hand ergänzt werden. Wir lösen das, indem ein Hub-Cluster pro Set die Add-ons fan-out auf Spokes verteilt — die Spokes haben damit keine eigene Operations-Oberfläche mehr.

Das Hub-Spoke-Muster ist in der ArgoCD-Dokumentation als „ApplicationSet" formalisiert. Praktisch heißt es: eine Änderung an einem Helm-Chart in Git triggert einen Sync auf allen Spokes binnen Minuten. Diff-Driver in ArgoCD zeigen die anstehende Änderung pro Cluster. Approval kann pro Set unterschiedlich konfiguriert werden — Production verlangt manuelle Bestätigung, Staging läuft automatisch.

Zero Trust: die meistunterschätzte Schicht

Zero-Trust ist der Teil, der am häufigsten unterschätzt wird. mTLS überall, Default-Deny zwischen Workloads, JWT-Validierung östlich-westlich. Wer das nicht von Tag eins integriert, baut sich später eine teure Migration ein. Wir setzen auf Cilium ^[7] als Network-Layer mit eBPF und Istio ^[8] als Mesh — die Kombination liefert L4-Default-Deny pro Namespace und L7-Verträge pro Service.

Die zugrunde liegende Architektur entspricht dem NIST Special Publication 800-204A „Building Secure Microservices-based Applications using Service-Mesh Architecture" ^[9]. Das Dokument beschreibt die Trennung von Identity-, Policy- und Data-Plane in Mesh-Architekturen und empfiehlt SPIFFE/SPIRE als Identitäts-Schicht — was Cilium und Istio beide unterstützen.

Was diese Stack-Wahl konkret an Mandat liefert

Konkret in unseren Mandaten: ein neuer Cluster geht in unter zwei Stunden in Produktion, ein neuer Tenant in unter 30 Minuten, ein Add-on-Update läuft in unter zehn Minuten über alle Sets. Audit-Anforderungen (BSI C5, ISO 27001) sind über Vault-Audit-Logs, ArgoCD-Sync-Historie und Cilium-Flow-Logs gedeckt. Disaster Recovery ist Cluster-Neubuild aus Git plus Vault-Restore — typischerweise unter zwei Stunden RTO.

Die Investition in diese Disziplin liegt im Bereich von acht bis sechzehn Wochen Einrichtung pro neuem Mandat. Die Auszahlung beginnt im sechsten Monat: ab dann ist Operations-Aufwand kleiner als die Senior-Stunden, die der Klient sonst für tägliche Cluster-Pflege bräuchte.

1. [1]
   Borg, Omega, and Kubernetes (Communications of the ACM)

   Burns, B., Grant, B., Oppenheimer, D., Brewer, E., Wilkes, J. (2016) · paper
2. [2]
   Terragrunt Documentation

   Gruntwork Inc. (2024) · docs
3. [3]
   HashiCorp Vault Documentation

   HashiCorp (2024) · docs
4. [4]
   External Secrets Operator Documentation

   External Secrets Inc. (2024) · docs
5. [5]
   NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management

   NIST (2020) · standard
6. [6]
   Argo CD Documentation

   The Argo Project (CNCF) (2024) · docs
7. [7]
   Cilium Documentation — eBPF-based Networking, Security, and Observability

   Isovalent / CNCF (2024) · docs
8. [8]
   Istio Documentation — Service Mesh

   The Istio Project (CNCF) (2024) · docs
9. [9]
   NIST SP 800-204A — Building Secure Microservices-based Applications Using Service-Mesh Architecture

   Chandramouli, R. (NIST) (2020) · standard
10. [10]
    RKE2 — Rancher Kubernetes Engine 2 (Government-Grade Distribution)

    SUSE / Rancher (2024) · docs