Die Souveränität einer cloudnativen Plattform wird nicht allein dadurch bestimmt, wo der Workload ausgeführt oder seine Daten gespeichert werden. Laut einer am 18. August 2026 veröffentlichten Analyse der CNCF, verfasst von Chamod Perera, CNCF Ambassador, und Suvin Kodituwakku, Senior Software Engineer bei WSO2, hängt der Nachweis der Souveränität auch davon ab, wo sich der Steuerungszustand befindet, über welche Pfade Logs und Metadaten laufen, welche Stellen auf Schlüssel und Zugangsdaten zugreifen können und ob das Team den Betrieb fortsetzen kann, wenn ein Dienst des Anbieters ausfällt.
Die Analyse schlägt vor, Souveränität als Eigenschaft der Plattformtopologie zu betrachten und nicht lediglich als Auswahl einer Region in einer Einstellungsliste. OpenChoreo, eine quelloffene interne Entwicklerplattform und ein Sandbox-Projekt der CNCF, dient dabei als überprüfbares Beispiel für diesen Ansatz. Die architektonischen Prinzipien sind jedoch nicht auf OpenChoreo beschränkt.
Vier Fragen, die über den Serverstandort hinausgehen
Dem Beitrag zufolge müssen Plattformteams angesichts von Rahmenwerken wie dem EU Data Act, NIS-2, DORA und dem UK Data Use and Access Act praktische Fragen beantworten, die über die Festlegung einer geografischen Region hinausgehen. Die erste lautet: Welcher Rechtsordnung unterliegt jede Komponente, die auf Mandantendaten zugreifen kann, einschließlich Steuerungs- und Protokollebene? Die zweite lautet: Kann das Team Workloads ausführen, neu erstellen und verschieben, wenn der beim Anbieter gehostete Dienst ausfällt?
Die beiden anderen Fragen betreffen die Möglichkeit des Zugriffs grenzüberschreitender Parteien auf Schlüssel, Clusterzustände oder administrative Zugangsdaten sowie die Frage, ob ein Wechsel des Anbieters, der Hardware oder des Landes eine Neuprogrammierung des Workloads erfordert. Die Analyse kommt zu dem Schluss, dass sich diese Fragen im Wesentlichen darauf konzentrieren, wo sich Steuerung und Zustand befinden und wer darauf zugreifen kann.
Wie funktioniert die Mehrebenenarchitektur?
OpenChoreo teilt die Plattform in unabhängige Cluster auf, von denen jeder seinen eigenen Lebenszyklus, seine eigenen Sicherheitsgrenzen und sein eigenes Skalierungsverhalten besitzt:
- Steuerungsebene: Sie hält den gewünschten Zustand über deklarierte APIs vor und führt die Abgleichskomponenten aus, führt jedoch keine Mandanten-Workloads aus.
- Datenebenen: Kompatible Kubernetes-Cluster führen die Workloads tatsächlich aus; jeder besitzt einen unabhängigen API-Server und einen unabhängigen Zustand.
- Überwachungsebenen: Sie sammeln und stellen Logs, Metriken und Traces bereit.
- Workflow-Ebenen: Sie führen CI- und GitOps-Prozesse aus.
- Erlebnisebene: Sie stellt ein Entwicklerportal, eine CLI, APIs und MCP bereit.
Das wichtigste Element ist das Kommunikationsmodell. Daten-, Überwachungs- und Workflow-Ebenen öffnen ausgehende, gegenseitig authentifizierte Verbindungen per mTLS zum Gateway der Steuerungsebene, während die Steuerungsebene keine Verbindungen zu ihnen initiiert. Dadurch sind die API-Server der Cluster, die regulierte Workloads hosten, nicht dem Internet ausgesetzt. Außerdem hält die Steuerungsebene den gewünschten Zustand und nicht den vollständigen Laufzeitzustand des Mandanten. Daher kann die Datenebene weiterhin Anfragen bedienen, selbst wenn die Verbindung zur Steuerungsebene verloren geht.
Was ändert sich dadurch praktisch für Plattformteams?
Jede Datenebene kann einer bestimmten Rechtsordnung zugeordnet werden, sodass das Modell „eine Rechtsordnung, eine Datenebene“ überprüfbar und auditierbar wird. Jede Datenebene sendet zudem ihre Betriebsdaten an eine regionale Überwachungsebene, anstatt Logs und Traces über die Steuerungsebene zu leiten. Dadurch bleiben Mandanten-Workloads und ihre Messdaten innerhalb der festgelegten regionalen Grenzen.
Die Möglichkeit, unabhängig vom Anbieter weiterzuarbeiten, beruht darauf, dass jede Datenebene ein vollständiger, kompatibler Kubernetes-Cluster ist und kein geschlossenes verwaltetes Endpunktangebot. Die Analyse verweist auf die Verwendung quelloffener Komponenten aus dem CNCF- und Cloud-Native-Ökosystem, etwa Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager und Cilium. Die modulare Architektur ermöglicht den Austausch einer Komponente oder die Anbindung einer bestehenden Überwachungsumgebung über dieselbe Abfrageschnittstelle.
Der Schutz von Secrets und Schlüsseln wird einem mit External Secrets Operator kompatiblen Speicher oder einem vom Betreiber ausgewählten Vault überlassen, anstatt standardmäßig den Besitz der Schlüssel vorzugeben. Außerdem lassen sich feingranulare Berechtigungen auf Ebene von Namespaces, Projekten und Komponenten anwenden. Gruppen können mit jedem OAuth2/OIDC-Identitätsanbieter verknüpft werden, unabhängig davon, ob der Aufrufer ein Entwickler, ein CLI-Tool oder ein Agent für künstliche Intelligenz ist.
Integration virtueller Cluster in die Plattformebenen
Dieses Modell ersetzt das Mandantencluster-Muster nicht, sondern ergänzt es. Ein virtueller Cluster gibt jedem Mandanten innerhalb eines gemeinsam genutzten Host-Clusters eine virtuelle Steuerungsebene, einen eigenen API-Server und einen eigenen Speicher. Dadurch wird der Steuerungszustand zwischen Mandanten zu geringeren Kosten isoliert als bei einem dedizierten Cluster für jeden einzelnen Mandanten. Allein dadurch wird jedoch weder bestimmt, in welcher Rechtsordnung der Mandant gehostet werden muss, wohin Logs gesendet werden oder wer berechtigt ist, den Workload zwischen zwei Umgebungen oder Regionen hochzustufen.
Hier fügt die Plattformebene Verteilungs- und Betriebssteuerungen hinzu. Eine DataPlane-Ressource kann das Kennzeichen der Rechtsordnung tragen und über observabilityPlaneRef mit einer regionalen Überwachungsebene verknüpft werden, während die Hochstufungspfade festlegen, zwischen welchen Umgebungen der Workload wechseln darf. Das Entwicklerportal stellt zudem vorgefertigte Pfade bereit, die den direkten Zugriff von Benutzern auf sensible Cluster überflüssiger machen.
Diese Kombination hat jedoch eine klare Grenze: Mandanten auf demselben Host teilen sich Knoten und Betriebssystemkernel. Wenn das Bedrohungsmodell eine hardwarebasierte Isolation jedes Mandanten verlangt, reicht ein virtueller Cluster nicht aus; dann ist eine tatsächlich unabhängige Datenebene erforderlich.
Souveränität als deklarative und auditierbare Konfiguration
Die Analyse schlägt vor, die Topologie über deklarierte Kubernetes-Ressourcen abzubilden und in Git zu speichern: Welche Region welche Datenebene verwendet, welches Ziel Überwachungsdaten empfängt und welche Hochstufungspfade zulässig sind. Dadurch wird die Einrichtung einer neuen Rechtsordnung zu einem überprüfbaren Pull Request, und die Antwort auf die Frage, warum sich Mandantendaten in einer bestimmten Region befinden, stützt sich auf eine Änderungshistorie und nicht auf einen Screenshot aus einem Dashboard.
Die Mehrebenenarchitektur ändert jedoch weder die Rechtsordnung der Stelle, die die Infrastruktur betreibt, noch beseitigt sie deren Unterstellung unter die für sie geltenden Rechtssysteme. Sie zieht Grenzen, setzt aber nicht allein die Richtlinien für das durch, was innerhalb dieser Grenzen geschieht. Lieferkettenattestierung, SBOM, Auditprotokollierung und die Identität von Workloads über Werkzeuge wie SPIFFE/SPIRE bleiben separate Kontrollen, die integriert werden müssen.
Als letzte Einschränkung kommen die Betriebskosten hinzu: Jeder zusätzliche Cluster benötigt Überwachung, Upgrades und Backups. Daher ist die Architektur dann gerechtfertigt, wenn die gezogenen Grenzen tatsächliches rechtliches oder sicherheitsbezogenes Gewicht haben, und kann in Umgebungen, die dies nicht benötigen, überdimensioniert sein. Zusammenfassend lässt sich sagen, dass die Kombination aus Mandantenclustern zur Ressourcenisolierung, einer Mehrebenenarchitektur zur Festlegung dessen, was Grenzen überschreiten darf, und deklarativen, versionsverwaltbaren Konfigurationen Souveränität von einem vertraglichen Versprechen in eine betreibbare und überprüfbare Eigenschaft verwandelt.