Die wichtigere Frage: Welche Risiken darf man teilen?
Mehrere Business-Teams können sich die Kubernetes-API, die Verfügbarkeit der Control Plane, Worker-Nodes, Cluster-Administratoren, Admission-Controller, CRDs, Container-Networking, Storage-Systeme, Ingress-/Gateway-Infrastruktur, Monitoring- und Backup-Plattformen teilen. Namespaces, RBAC, Quotas, NetworkPolicies, Pod-Security-Kontrollen und Workload-Identität können unerwünschten Zugriff verringern — sie machen aus einem Cluster aber nicht automatisch mehrere getrennte Umgebungen.
Die richtige Frage lautet nicht „Wie viele Teams passen in einen Cluster?" — sondern „Welche Risiken dürfen diese Teams gemeinsam tragen?"
Soft Multi-Tenancy versus Hard Multi-Tenancy
Namespaces allein reichen selten aus, um sich gegen einen feindseligen Mandanten zu isolieren.
Namespace-basierte Tenancy — und was sie nicht isoliert
Namespaces teilen Cluster-Ressourcen zwischen mehreren Nutzern auf und bieten einen Geltungsbereich für RBAC-Roles, NetworkPolicies, ResourceQuotas, LimitRanges und Pod-Security-Admission-Labels. Kubernetes-Namespaces können nicht verschachtelt werden.
Ein Namespace ist eine organisatorische Grenze und eine Policy-Grenze — er ist keine eigene Control Plane. Mandanten in unterschiedlichen Namespaces teilen sich weiterhin API-Server, Scheduler, etcd, Nodes, die Container-Runtime, CNI/CSI, clusterweite Ressourcen, ClusterRoles, CRDs und Admission-Webhooks. Ein Ausfall oder eine privilegierte Änderung in einer geteilten Komponente kann jeden Namespace betreffen.
Identität, RBAC und Netzwerkisolation
Jeder Mandant sollte benannte Identitäten und Gruppen haben, statt Zugriff direkt an Einzelpersonen zu vergeben. Kubernetes-RBAC regelt den API-Zugriff über Roles, ClusterRoles, RoleBindings und ClusterRoleBindings — Least Privilege zählt, weil manche namespace-gebundenen Berechtigungen trotzdem zu weitreichendem Zugriff führen: Pods erstellen, Secrets lesen oder beliebige PVCs mounten können mehr offenlegen, als der Ressourcenname vermuten lässt.
Netzwerkisolation
NetworkPolicy steuert, wie ausgewählte Pods kommunizieren dürfen, sofern die CNI-Implementierung sie durchsetzt. Eine übliche Basiskonfiguration pro Mandant ist Default-Deny für Ingress und Egress mit expliziten Regeln für DNS-, Datenbank- und Monitoring-Zugriff.
Compute-Isolation: Quotas, Priorität und Node Pools
Eine ResourceQuota begrenzt den gesamten Verbrauch oder die Objektanzahl innerhalb eines Namespace — aber eine Quota ist keine reservierte Kapazität. Sie definiert ein Maximum; sie garantiert nicht, dass der Cluster genug freie Kapazität hat, damit der Mandant den vollen Betrag nutzen kann. Für garantierte Kapazität prüfen Sie dedizierte Node Pools, Mindest-Node-Anzahlen oder einen separaten Cluster.
Storage- und Secret-Tenancy
Eine PVC ist namespace-gebunden, aber diese Grenze kann eine unsichere externe Storage-Konfiguration nicht korrigieren — weitreichende Pod-Erstellungsrechte in einem anderen Namespace, geteilte Storage-Zugangsdaten oder wiederverwendete Verschlüsselungsschlüssel können sie alle umgehen. Nutzen Sie mandantenspezifische StorageClasses, Buckets oder Prefixes, Service-Identitäten und Verschlüsselungsschlüssel für Objektspeicher.
Auch Secrets sind namespace-gebunden, aber der Zugriff der Mandanten hängt weiterhin von RBAC und Workload-Berechtigungen ab — schützen Sie Lesezugriff auf Secrets, Pod-Erstellung, Debug-Container und Backup-Exporte als eine einzige Berechtigungsfläche, nicht getrennt voneinander.
Tenancy bei Backup, Monitoring und Kosten
Eine geteilte Backup-Plattform muss festlegen, wer Richtlinien erstellt, wer namespaceübergreifend wiederherstellen darf und wer Secrets wiederherstellen darf — ein Restore für einen Mandanten darf niemals die Ressourcen eines anderen Mandanten überschreiben oder offenlegen. Testen Sie Restore im selben Namespace, Restore in einen anderen Namespace und Restore im Ersatz-Cluster mit mandantenspezifischen Zugangsdaten.
Ein geteiltes Monitoring-System kann Logs, Traces und Infrastrukturdaten über Mandantengrenzen hinweg offenlegen — definieren Sie Query-Isolation, Aufbewahrung und die Filterung sensibler Daten. Bei den Kosten sollte das Chargeback CPU-/Memory-Nutzung, Storage, Netzwerktransfer, Load Balancer und Backup umfassen — ein reines Nutzungs-Chargeback kann Kapazität unterbewerten, die für einen Mandanten reserviert, aber zur Verfügbarkeit ungenutzt vorgehalten wird.
Die richtige Isolationsgrenze wählen
Notfallwiederherstellung für geteilte Cluster
Die Wiederherstellung eines geteilten Clusters muss alle Mandanten berücksichtigen — nicht jeder Mandant kehrt gleichzeitig zurück. Klassifizieren Sie Plattformdienste, kritische Kundenanwendungen, wichtige Business-Workloads und entbehrliche Umgebungen in Wiederherstellungsstufen, und planen Sie dann Mindest-Node-Anzahl und Quota für kritische Mandanten in der Wiederherstellungsumgebung, da diese anfangs möglicherweise nicht der Produktionskapazität entspricht.
Häufige Fehler bei Multi-Tenant-Kubernetes
Mandanten teilen sich weiterhin Control Plane, Nodes, Kernel, CRDs und Plattformdienste. Nutzen Sie mehrschichtige Isolation oder separate Cluster.
Ein Mandant kann jeden Workload beeinflussen. Nutzen Sie namespace-gebundenes RBAC.
Eine Quota reserviert kein Compute. Halten Sie ausreichend Cluster-Kapazität vor, um sie zu decken.
Das gewählte CNI setzt möglicherweise nicht jedes erwartete Verhalten durch. Testen Sie die Implementierung.
Unabhängige Anwendungen erben dieselben Berechtigungen. Nutzen Sie Workload-spezifische Identitäten.
Ein Namespace kann auf die Daten eines anderen Mandanten zugreifen. Nutzen Sie mandantenspezifische Identitäten und Buckets oder Prefixes.
Dem Wiederherstellungs-Cluster kann die Kapazität ausgehen. Nutzen Sie Wiederherstellungsprioritäten.
Geteilte Dienste, Reservierungen, Storage und Backup bleiben unberücksichtigt. Nutzen Sie ein vollständiges Kostenmodell.
Checkliste für Multi-Tenant-Kubernetes
0 / 24Häufig gestellte Fragen
Es ist ein Betriebsmodell für Kubernetes, bei dem sich mehrere Teams, Anwendungen, Kunden oder Umgebungen eine Kombination aus Control Plane, Worker-Nodes und Plattformdiensten teilen.
Namespaces bieten einen nützlichen Rahmen für Policy und Organisation, sind aber keine vollständigen harten Sicherheitsgrenzen, da Mandanten sich weiterhin Nodes, die Control Plane, CRDs und clusterweite Dienste teilen können.
Nein. Kubernetes-Namespaces können nicht verschachtelt werden.
Normalerweise nicht. cluster-admin kann den gesamten Cluster und jeden Mandanten beeinflussen.
Sie begrenzt den gesamten Ressourcenverbrauch oder die Objektanzahl innerhalb eines Namespace.
Nein. Sie definiert ein Maximum, garantiert aber nicht, dass der Cluster über freie Kapazität verfügt.
Sie definiert erlaubte Netzwerkkommunikation für ausgewählte Pods, sofern die CNI-Implementierung NetworkPolicy unterstützt und durchsetzt.
Nein. Die Durchsetzung hängt vom CNI und dem genauen Traffic-Pfad ab. Testen Sie die gewählte Netzwerk-Implementierung.
Nein. Sie verbessern die Trennung von Compute und Kernel, aber Mandanten können sich weiterhin die Kubernetes Control Plane und clusterweite Dienste teilen.
Nutzen Sie kontrollierte, von der Plattform freigegebene Klassen. Uneingeschränkte Priorität kann es einem Mandanten erlauben, einen anderen zu stören.
Nutzen Sie separate Cluster, wenn sich Administrator-Vertrauen, Compliance, Upgrade-Zeitplan, Sicherheitsrichtlinie, Blast Radius, clusterweite Anpassungen oder die Zuständigkeit für die Wiederherstellung unterscheiden müssen.
Testen Sie RBAC, namespaceübergreifenden Zugriff, Netzwerkisolation, Quotas, Noisy-Neighbor-Verhalten, Node-Trennung, Backup-Wiederherstellung, Incident-Quarantäne und die Wiederherstellung im Ersatz-Cluster.
Teilen Sie nur die Risiken, die das Unternehmen akzeptiert
Multi-Tenant-Kubernetes kann eine effiziente Plattform für mehrere Business-Teams bieten. Namespaces, RBAC, NetworkPolicies, Quotas, LimitRanges, Pod-Security-Kontrollen, Workload-Identitäten und dedizierte Node Pools schaffen nützliche Trennung — sie beseitigen aber nicht die geteilte Control Plane, Cluster-Administratoren, Nodes, Storage oder den Upgrade-Lebenszyklus.
Klassifizieren Sie das Vertrauen der Mandanten, identifizieren Sie jede geteilte Ausfalldomäne, schränken Sie namespace- und clusterweite Berechtigungen ein, kontrollieren Sie Netzwerk und Cloud-Identität, trennen Sie sensiblen Storage- und Backup-Zugriff, und verteilen Sie geteilte Kosten transparent. Nutzen Sie dedizierte Nodes, wo Compute-Trennung ausreicht, und separate Cluster, wo administrative, regulatorische oder Blast-Radius-Trennung erforderlich ist. Das Ziel ist, die Plattform nur dort zu teilen, wo das geteilte Risiko akzeptabel, messbar und wiederherstellbar bleibt.