Cloud Native Plattform-Souveränität durch Multi-Plane-Architektur

TL;DR

Cloud-Souveränität erfordert eine durchdachte Architektur, die Kontrolle, Runtime, Build und Observabilität über Cluster hinweg trennt. Die Multi-Plane-Architektur, wie sie im OpenChoreo-Projekt implementiert ist, ermöglicht es, regulatorische Anforderungen besser zu erfüllen und die Sicherheit von Tenant-Daten durch klare juristische Grenzen zu gewährleisten.

Hauptinhalt

In der Diskussion um Cloud-Souveränität wird oft der Standort von Workloads und Daten als zentral betrachtet. Jedoch ist die Architektur der Plattform ebenso entscheidend. Die Trennung von Verantwortlichkeiten für Kontrolle, Ausführung, Build-Prozesse und Observabilität über verschiedene Cluster hinweg ist von großer Bedeutung, insbesondere im Kontext gesetzlicher Anforderungen wie dem EU Data Act oder dem UK Data Use and Access Act.

Ein kürzlich veröffentlichter Beitrag innerhalb der CNCF-Community hat vier zentrale Fragen formuliert, die Auditoren und Beschaffungsteams an Plattform-Teams stellen. Diese Fragen zielen darauf ab, die rechtlichen Rahmenbedingungen und die Sicherheitsmaßnahmen der Plattform zu klären. Dazu gehören unter anderem die rechtliche Jurisdiktion für alle Komponenten, die mit Tenant-Daten interagieren, sowie die Fähigkeit, Workloads unabhängig von einem Anbieter weiterzuführen.

Ein einzelner, gemeinsamer Kubernetes -Cluster erschwert es, klare architektonische Grenzen zu definieren. Mit der Einführung des Tenant-Cluster-Musters, bei dem jede Grenze ihre eigene Steuerungsebene erhält, wird diese Problematik angegangen. Darüber hinaus bietet die Multi-Plane-Architektur eine zusätzliche Lösung, indem sie die Plattform in verschiedene Ebenen unterteilt.

OpenChoreo, ein Open-Source-Projekt und CNCF-Sandbox-Projekt, demonstriert diese Multi-Plane-Architektur. Die Architektur gliedert sich in mehrere Ebenen:

• Control Plane: Verwalten des gewünschten Zustands über deklarative APIs und Ausführung der Reconciliation-Controller. Diese Ebene orchestriert, führt jedoch keine Tenant-Workloads aus.
• Data Planes: Konformitäts-Kubernetes -Cluster, die tatsächlich die Workloads ausführen und jeweils ihre eigene API-Server und ihren eigenen Zustand besitzen.
• Observability Planes: Erfassen und Bereitstellen von Protokollen, Metriken und Traces.
• Workflow Planes: Ausführen von CI- und GitOps-Workflows.
• Experience Plane: Bereitstellung des Entwicklerportals sowie von CLI- und API-Oberflächen.

Die Verbindungsmodelle zwischen diesen Ebenen sind entscheidend für die Souveränität. Die Daten-, Observabilitäts- und Workflow-Ebenen stellen jeweils eine outbound-verbindungsbasierte, gegenseitig authentifizierte Verbindung zum Gateway der Steuerungsebene her. Dadurch wird gewährleistet, dass die API-Server der Cluster, die regulierte Workloads halten, nicht dem Internet ausgesetzt sind.

Technische Details/Implikationen

Die Multi-Plane-Architektur ermöglicht es, die regulatorischen Anforderungen klar zu adressieren. Durch das Modell “eine Jurisdiktion, ein Datenraum” kann die Architektur während eines Audits leicht verteidigt werden. Die Trennung der Zuständigkeiten sorgt dafür, dass die Steuerungsebene den gewünschten Zustand hält, während die Datenebenen unabhängig von dieser arbeiten können. Dies reduziert die Abhängigkeiten und erhöht die Sicherheit, da die Runtime-Zustände nicht zentralisiert werden.

Fazit/Ausblick

Die Implementierung einer Multi-Plane-Architektur bietet eine vielversprechende Lösung für die Herausforderungen der Cloud-Souveränität. Durch die klare Trennung von Verantwortlichkeiten und die Einhaltung regulatorischer Anforderungen können Plattform-Teams die Sicherheit und Integrität ihrer Systeme verbessern.