Mandanten-Isolation: wenn eine logische Grenze keine Netzwerk-Grenze ist
Eine logische Grenze ist keine Netzwerk-Grenze
Ein Namespace in Kubernetes sieht nach einer sauberen Trennung aus: eigene Ressourcen, eigener Name, eigene Rechte. Trotzdem kann ohne weitere Konfiguration jeder Pod jeden anderen Pod über Namespace-Grenzen hinweg erreichen. Ein Namespace ist eine organisatorische Grenze für Namen, Rollen und Richtlinien, keine Netzwerk-Grenze. Wer das verwechselt, hält eine Umgebung für isoliert, die es technisch nicht ist.
Drei Mechanismen, drei unterschiedliche Aufgaben
Echte Isolation entsteht erst aus dem Zusammenspiel mehrerer Mechanismen, die jeweils eine eigene Frage beantworten. ResourceQuota beantwortet: wie viel CPU, Speicher und wie viele Objekte darf eine Umgebung insgesamt belegen, damit sie nicht die Nachbarn aushungert. LimitRange geht eine Ebene tiefer und setzt Grenzen pro einzelnem Container, fängt also eine einzelne fehlkonfigurierte Anwendung ab, bevor sie überhaupt zum Problem für andere wird. NetworkPolicy schließlich regelt, welcher Pod mit welchem sprechen darf, und das nur, sofern der Cluster ein CNI-Plugin betreibt, das diese Regeln tatsächlich durchsetzt. Ohne ein solches Plugin werden NetworkPolicy-Objekte zwar akzeptiert, wirken aber nicht, ein Detail, das bei einer Cluster-Konfiguration leicht übersehen wird.
Weich oder hart, je nach Vertrauen
Kubernetes unterscheidet zwischen weicher und harter Mandantentrennung. Weiche Multi-Tenancy reicht, wenn alle Umgebungen demselben Vertrauensrahmen angehören, etwa verschiedene Projekte desselben Teams. Harte Multi-Tenancy braucht deutlich mehr, da sie unterstellt, dass eine Umgebung sich aktiv gegen eine andere absichern muss, nicht nur versehentliche Kollisionen vermeiden soll. Welcher Grad angemessen ist, entscheidet sich an der Frage, ob sich alle Beteiligten gegenseitig vertrauen oder ob diese Annahme nicht trägt.
Der Nutzen zeigt sich erst im Fehlerfall
Im Normalbetrieb ist Mandanten-Isolation unsichtbar, sie kostet nichts an Komfort und fällt niemandem auf. Relevant wird sie genau dann, wenn eine Umgebung ein Problem hat: ein Speicherleck, eine fehlerhafte Deploy, ein Angriffsversuch. Sauber gezogene Grenzen entscheiden, ob ein solches Problem auf seine eigene Umgebung begrenzt bleibt oder sich ausbreitet. Das ist kein Feature, das man vorführt, sondern eines, dessen Fehlen man erst bemerkt, wenn es zu spät ist.
Was das für TYPO3-Hosting bedeutet
Läuft TYPO3-Hosting für mehrere Projekte auf derselben Cluster-Infrastruktur, ist diese Frage keine theoretische mehr. Wichtig ist dann zu wissen, auf welcher Ebene die Trennung tatsächlich greift, organisatorisch, ressourcenseitig oder netzwerkseitig, denn das sind drei verschiedene Zusagen. Wie wir TYPO3-Betrieb über mehrere Projekte hinweg organisieren, beschreiben wir auf der Seite TYPO3-Wartung, Support und Hosting.
Quellen: Kubernetes-Dokumentation zu Resource Quotas, Kubernetes-Dokumentation zu Limit Ranges, Kubernetes-Dokumentation zu Network Policies.
