Sovereign by Design: Eine souveräne Plattform auf Kubernetes bauen

„Souveräne Cloud“ ist derzeit der lauteste Begriff in der europäischen IT — und das meiste davon ist ein Aufkleber. Anbieter kleben ihn auf eine Region, eine Vertragsklausel oder ein Compliance-Zertifikat und nennen die Plattform souverän. Aber Souveränität kauft man nicht an der Kasse — sie ist eine Eigenschaft davon, wie du entwirfst. Ist sie nicht eingebaut, bringt sie kein Label hinein.

Das hier ist eine praxisnahe, anbieterneutrale Architektur, um eine wirklich souveräne Plattform zu bauen. Die Kernidee: Souveränität nicht als eine zu beschaffende Sache behandeln, sondern als drei unabhängige Schichten, für die du entwirfst — mit Kubernetes als Portabilitäts-Rückgrat, das sie verbindet.

Das baut auf einem Sicherheitsfundament auf, ersetzt es nicht. Ist deine Plattform nicht zuerst gehärtet, ist Souveränität irrelevant — starte mit der Secure-by-Default-GKE-Referenzarchitektur und lege Souveränität darüber.

Souveränität besteht aus drei Schichten, nicht aus einer

Der größte Fehler ist, „souverän“ als Binärzustand zu behandeln, den man hat oder nicht. Es sind in Wahrheit drei getrennte Fragen — eine Plattform kann bei einer stark abschneiden und bei einer anderen durchfallen.

• Datensouveränität — Wo liegen die Daten physisch, und wer kann rechtlich Zugriff erzwingen? Residency ist nur die halbe Miete; die rechtliche Reichweite über den Betreiber ist die andere.
• Betriebssouveränität — Wer betreibt die Steuerungsebene? Wer kann das laufende System lesen, administrieren oder gezwungen werden, es offenzulegen?
• Technische Souveränität — Kannst du gehen? Sind deine Workloads portabel oder an die proprietären APIs eines Anbieters geschweißt?

Ein typisches „souveränes“ Angebot deckt eine davon überzeugend ab und winkt beim Rest ab. Echte Souveränität heißt, für alle drei zu entwerfen — nehmen wir sie in der Reihenfolge, die den größten Hebel gibt.

Die Freiheit zu gehen: Portabilität als der echte Test

Technische Souveränität hat einen brutal einfachen Test: Was kostet es dich zu gehen?

Bedeutet das Verlassen eines Anbieters, deine Anwendungen neu zu schreiben und um andere proprietäre Dienste herum neu zu architektieren, bist du gefangen — und Lock-in ist das genaue Gegenteil von Souveränität. Bedeutet Weggehen, dieselben Manifeste auf einem anderen konformen Cluster neu auszurollen, bist du auf der technischen Schicht souverän.

Hier verdient sich Kubernetes seinen Platz — nicht als Container-Scheduler, sondern als Portabilitätsschicht. Standard-Kubernetes-Manifeste, OCI-Images, Helm-Charts und Infrastructure-as-Code sind über jede große Plattform und On-Premises konform. Der Workload ändert sich nicht, wenn sich der Boden darunter ändert.

Portabilität ist aber nicht gratis. Der Workload-Kern reist mit; die Ränder nicht — Storage Classes, Ingress-Controller, LoadBalancer-Annotationen und Cloud-Identity-Integration sind anbieterspezifisch und müssen bewusst abstrahiert oder getauscht werden. Echte Portabilität heißt, diesen Kern sauber und die anbieterspezifischen Ränder dünn und austauschbar zu halten — nicht so zu tun, als ändere sich beim Umzug nichts.

Die Disziplin besteht darin, deinen kritischen Pfad auf portablen, standardbasierten Komponenten zu halten und jeden proprietären Managed Service als bewussten Kompromiss zu behandeln. Eine Queue als Kubernetes-Workload zieht überallhin; eine Queue, die eine anbieterspezifische API ist, ist ein Anker.

# Portabel: der Workload ist ein Standard-Objekt, keine Vendor-API.
# Dasselbe Manifest läuft auf GKE, EKS, AKS oder einem EU-gehosteten Cluster.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingest
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: ingest
          image: registry.example.eu/ingest:1.8.0   # deine Registry, deine Region
          envFrom:
            - secretRef:
                name: ingest-config

Portabilität heißt nicht, nie einen Managed Service zu nutzen. Sie heißt, für jeden zu wissen, was das Verlassen genau kosten würde — damit „wir könnten wechseln“ ein gemessener Ausstiegsplan ist und kein beruhigender Slogan.

Wer hält die Schlüssel: Residency ist nicht Hoheit

Hier ist die Falle, die die meisten „unsere Daten liegen in einer EU-Region, also sind wir souverän“-Behauptungen versenkt.

Data Residency wählt, wo die Bytes liegen. Sie sagt nichts darüber, wer sie lesen kann. Ein Anbieter unter fremdem Rechtsregime — der US CLOUD Act ist das Paradebeispiel — kann gezwungen werden, Daten herauszugeben, egal in welcher Region sie liegen. Residency allein stoppt das nicht.

Der Kontrollpunkt, der das Ergebnis wirklich ändert, ist Schlüsselhoheit. Was sie wirklich liefert, ist HYOK (Hold Your Own Key) — ein externer Key Manager wie Googles External Key Manager (EKM) oder AWS XKS, bei dem der Anbieter zum Entschlüsseln deinen Key-Dienst aufruft und das Schlüsselmaterial nie selbst hält. Reines BYOK, bei dem du einen Schlüssel in das KMS des Anbieters importierst, ist schwächer: Der Anbieter hält den Schlüssel dann doch und schützt gegen eine andere, kleinere Bedrohung. Bei echter externer Hoheit gilt:

• Der Anbieter speichert deine Daten verschlüsselt, und Ciphertext ohne deinen Schlüssel ist Rauschen.
• Wird er rechtlich zur Herausgabe gezwungen, kann er nur denselben wertlosen Ciphertext produzieren.
• Widerrufe den Zugriff auf den Schlüssel und neue Entschlüsselungen stoppen überall auf einmal — bereits gecachte Data Keys laufen kurz danach aus — was effektiv Crypto-Shredding der Daten ist.

Residency und Schlüsselhoheit ergänzen sich: Residency beantwortet „wo“, Hoheit beantwortet „wer kann es lesen“. Die Hoheit macht aus einer rechtlichen Anfrage einen Nicht-Vorfall.

Schlüssel sind auch auf der Identitätsschicht das ganze Spiel. Dasselbe Prinzip „kein langlebiges Geheimnis zum Beschlagnahmen“ gilt für Workload-Credentials — siehe Schluss mit Service-Account-Schlüsseln mit Workload Identity Federation.

Betriebssouveränität: Wer kann es lesen und betreiben

Die leiseste Schicht ist die betriebliche. Selbst mit portablen Workloads und kundengehaltenen Schlüsseln leckt Souveränität, wenn die Betreiber der Ebene deine Systeme still von außerhalb deiner Jurisdiktion lesen oder administrieren können.

Für Betriebssouveränität zu entwerfen heißt:

• EU-only-Betrieb für regulierte Workloads — Support und Administration innerhalb der Jurisdiktion, nicht global geroutet.
• Access Transparency — jeder anbieterseitige Zugriff auf deine Umgebung wird protokolliert und ist für dich sichtbar, sodass aus „vertrau uns“ ein „überprüfe“ wird.
• Least Privilege und Just-in-Time-Zugriff — kein stehender Admin-Zugriff; Elevation ist scoped, zeitlich begrenzt und auditiert.
• Dein eigener Audit-Trail — Logs in Speicher, den du kontrollierst, damit der Nachweis, wer was getan hat, nicht vom Wohlwollen des Anbieters abhängt.

Nichts davon ist exotisch. Es ist dieselbe Zugriffskontroll-Disziplin, die du bereits auf deine eigenen Teams anwendest — erweitert auf den Anbieter als nicht vertrauenswürdigen Betreiber.

Souveränität ohne Dogma: Ein Entscheidungsrahmen

Der Fehlermodus auf der anderen Seite ist, Souveränität als Reinheitstest zu behandeln und eine schwere Velocity-Steuer zu zahlen, um eine Marketing-Broschüre mit null echten Workloads zu bauen. Souveränität ist ein Spektrum, und du wendest sie per Klassifizierung an, nicht per Reflex.

Ein pragmatischer Rahmen:

1. Klassifiziere den Workload. Regulierte oder hochsensible Daten, oder ein System, dessen Kompromittierung existenziell ist? Es verdient die volle Behandlung: portable Komponenten, externe Schlüsselhoheit, Betriebskontrollen. Ein zustandsloses internes Tool ohne sensible Daten? Ein bequemer Managed Service ist ein völlig rationaler Kompromiss.
2. Miss das Lock-in, nimm es nicht an. Notiere für jede proprietäre Abhängigkeit im kritischen Pfad die echten Kosten des Weggehens. Manche sind billig zu tauschen; manche sind Anker. Du kannst nicht steuern, was du nicht gemessen hast.
3. Entwirf den Ausstieg, bevor du ihn brauchst. Portabilität, die nie geübt wurde, ist Hoffnung, keine Fähigkeit. Halte die Option echt: Standard-Manifeste, deine eigene Registry, Schlüssel, die du hältst, Infrastructure-as-Code, die eine zweite Plattform ansteuern kann.

So angewandt hört Souveränität auf, ein Glaubensstreit zu sein, und wird zu einem Engineering-Kompromiss, den du bewusst triffst — Workload für Workload.

Die ehrlichen Grenzen

Souveränität hat einen Preis, und das Gegenteil zu behaupten führt dazu, sie zu bereuen. Portable, standardbasierte Komponenten bedeuten manchmal, auf den schicksten proprietären Dienst zu verzichten. Externe Schlüsselhoheit fügt Betriebskomplexität und einen eigenen Fehlermodus hinzu — verlierst du den Schlüssel, sind die Daten wirklich weg. Volle Betriebssouveränität kann Support-Kosten erhöhen. Und keine Architektur entfernt die rechtliche Realität, dass du, wenn du überhaupt bei einem Anbieter läufst, etwas vertraust.

Der Punkt ist nicht maximale Souveränität überall. Er ist, dass Souveränität zu einer Eigenschaft wird, die du bewusst entworfen hast — gemessen, klassifiziert und geübt — statt zu einem Aufkleber, den dir jemand verkauft hat. Baue die drei Schichten bewusst, halte den Ausstieg echt, halte deine eigenen Schlüssel, und „souverän“ hört auf, eine Behauptung zu sein, die hoffentlich der Prüfung standhält, und wird zu einer, die du tatsächlich belegen kannst.