Digitale Souveränität mit Kubernetes: Wann ist Open Source wirklich souverän?

Kubernetes stammt von Google. Trotzdem setzen europäische Unternehmen und Behörden es als Grundlage ihrer souveränen Cloud-Strategie ein. Das ist kein Widerspruch, wenn man versteht, welche Dimension von Souveränität wirklich entscheidend ist.

Die Debatte dreht sich oft um die falsche Frage. Nicht „Wurde der Code in der EU geschrieben?" ist relevant, sondern: „Wer kontrolliert zur Laufzeit den Zugriff auf meine Daten und Systeme?" Dieser Artikel erklärt den Unterschied, warum er in der Praxis zählt, und was Kubernetes damit zu tun hat.

Was digitale Souveränität konkret bedeutet

Der Begriff wird viel verwendet, aber selten klar definiert. Für den Kontext von Cloud-Infrastruktur lassen sich drei Dimensionen unterscheiden :

• Datenhoheit: Kontrolle darüber, wo Daten liegen, wer darauf zugreifen kann und wie sie verarbeitet werden.
• Betriebshoheit: Kontrolle über den Betrieb der Plattform (Admin-Zugriffe, Updates, Incident-Handling, Schlüsselverwaltung).
• Rechtliche Immunität: Absicherung durch anwendbares Recht und Gerichtsstand (z. B. EU-/DE-Recht, Schutz vor extraterritorialen Zugriffsansprüchen).

Diese drei Dimensionen sind verwandt, aber nicht identisch. Ein Tool kann in Dimension drei stark sein und gleichzeitig in Dimension eins oder zwei versagen, je nachdem, wie es eingesetzt wird.

In einem vorherigen Blog haben wir das Thema Cloud Sovereignity Framework beschrieben, indem die Themen Datenhoheit, Betriebshoheit und Rechtliche Immunität und was Souveränität ist und wie sie gemessen wird eine zentrale Rolle spielen. Dieses findet ihr in unserem Cloud Sovereignty Framework Artikel.

Kubernetes und seine Wurzeln bei Google

Google hat Kubernetes 2014 als Open-Source-Projekt veröffentlicht, basierend auf internen Systemen wie Borg. 2016 wurde das Projekt an die Cloud Native Computing Foundation (CNCF) übergeben, die Teil der Linux Foundation ist. Heute ist Kubernetes eines der aktivsten Open-Source-Projekte weltweit, mit Maintainern aus Dutzenden von Unternehmen und Organisationen.

Der Code steht unter der Apache-2.0-Lizenz einer der permissivsten Open-Source-Lizenzen überhaupt. Das bedeutet: Jede Organisation kann Kubernetes verwenden, modifizieren, distribuieren und kommerziell einsetzen, ohne Lizenzgebühren zu zahlen oder Quellcode zurückgeben zu müssen.

Die CNCF als Governance-Modell

Was viele nicht wissen: Google hat formal kein Vetorecht mehr über die Richtung von Kubernetes. Die CNCF-Governance regelt, wie Entscheidungen getroffen werden. Das Kubernetes Steering Committee und das Technical Oversight Committee setzen sich aus Mitgliedern verschiedener Unternehmen zusammen. Kein einzelner Konzern bestimmt die Roadmap.

Das ist eine relevante Eigenschaft für Souveränitätsfragen, weil es bedeutet, dass der Fortbestand und die Entwicklung des Projekts nicht an das Schicksal eines einzelnen Unternehmens gebunden sind.

Open Source als Souveränitätsfaktor, aber nicht allein entscheidend

Offener Quellcode bietet echte Vorteile für digitale Souveränität: Der Code ist auditierbar. Sicherheitslücken können von der Community gefunden und gemeldet werden. Es gibt keinen Vendor-Lock-in auf Lizenzebene. Wer will, kann forken.

Trotzdem ist Open Source kein Freifahrtschein. Die entscheidende Frage ist nicht, wo der Code herkommt, sondern wo er läuft.

Der entscheidende Unterschied: Wo läuft der Code?

Ein Kubernetes-Cluster, der auf AWS, GCP oder Azure in einer US-Region betrieben wird, unterliegt US-amerikanischem Recht, auch wenn Kubernetes selbst Open Source ist. Das CLOUD Act von 2018 verpflichtet US-amerikanische Unternehmen unter bestimmten Umständen, Behörden Zugriff auf Daten zu gewähren, unabhängig davon, wo diese Daten physisch gespeichert sind.

Das bedeutet: Wer Kubernetes auf einem US-Hyperscaler betreibt, hat möglicherweise eine offene Flanke in der Datensouveränität, nicht wegen Kubernetes, sondern wegen des Betriebsmodells. Warum allein die Wahl einer EU-Region das Problem nicht löst, erklärt unser Artikel zu Datenresidenz vs. Datensouveränität.

Dreht man das um: Kubernetes, betrieben auf eigener Hardware oder in einem EU-Rechenzentrum eines europäischen Anbieters, ohne Vertragsbeziehung zu einem US-Unternehmen, ist eine substanziell andere Ausgangssituation.

Digitale Souveränität mit Kubernetes in der Praxis

Was bedeutet das für die Architekturentscheidung? Einige Leitlinien, die in der Praxis den Unterschied machen:

Betriebsort: Kubernetes-Cluster sollten in Rechenzentren laufen, die ausschließlich EU-Recht unterliegen. ISO 27001 und keine Konzernmuttergesellschaft in den USA sind sinnvolle Mindestanforderungen.

Managed vs. Self-Managed: Wer Kubernetes selbst betreibt, hat maximale Kontrolle, trägt aber den operativen Aufwand. Managed Kubernetes-Angebote von europäischen Anbietern können eine gute Balance sein, sofern die Betreiber die oben genannten Anforderungen erfüllen.

Supply-Chain: Welche Container-Images, Helm Charts und Operator-Deployments werden genutzt? Auch hier gilt: Open Source ist besser auditierbar als proprietäre Software, aber kein Automatismus für Sicherheit.

Der CLOUD Act und seine Auswirkungen

Der Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) erlaubt US-Behörden, bei US-Unternehmen die Herausgabe von Daten zu verlangen, die außerhalb der USA gespeichert sind. Das betrifft AWS, Microsoft, Google und andere Hyperscaler direkt.

Für europäische Organisationen, die sensible Daten verarbeiten, wie Gesundheitsdaten, Behördendaten, Daten nach NIS2 oder DSGVO, ist das ein reales Risiko. Es hat nichts damit zu tun, ob Kubernetes Open Source ist oder nicht. Es geht darum, mit wem der Betriebsvertrag geschlossen wird.

Wann ist Kubernetes wirklich souverän?

Eine pragmatische Checkliste für Teams, die diese Frage für ihre Organisation klären wollen:

• Betreiber: Ist der Betreiber ein Unternehmen mit Sitz ausschließlich in der EU, ohne US-amerikanische Konzernmutter?
• Rechenzentrum: Befindet sich die Infrastruktur in einem EU-Rechenzentrum, das ausschließlich EU-Recht unterliegt?
• Vertragliche Lage: Gibt es keine Vertragsbeziehungen, die US-Behörden Zugriff auf Daten ermöglichen könnten?
• Auditierbarkeit: Werden nur Open-Source-Komponenten eingesetzt, deren Code öffentlich einsehbar ist?
• Portabilität: Ist die Architektur so gestaltet, dass ein Wechsel des Betreibers ohne Datenverlust möglich wäre?

Wer alle fünf Punkte bejahen kann, betreibt Kubernetes souverän, unabhängig davon, dass der Code ursprünglich bei Google entstand.

Die Herkunft des Codes ist eine Frage der Geschichte. Die Kontrolle über den Betrieb ist eine Frage der Gegenwart.

Wer Kubernetes in einer souveränen Umgebung betreiben will, ohne den Aufwand eines vollständigen Selbstbetriebs, ist bei lowcloud richtig: eine Kubernetes-basierte PaaS, betrieben ausschließlich in deutschen Rechenzentren unter EU-Recht. Kein US-Hyperscaler, keine Abhängigkeiten, die die Betriebssouveränität untergraben.