Kubernetes-Provider mit DSGVO-Fokus finden

TL;DR

DSGVO-konform ist kein Logo auf der Website. Für einen Kubernetes-Provider zählen fünf Dinge: Verarbeitungsstandort, Auftragsverarbeitungsvertrag, dokumentierte TOMs, benannte Subunternehmer und ein Exit, der nicht an eine proprietäre Control Plane gebunden ist. Hyperscaler können das erfüllen. Ein deutscher Betreiber kann es auch, und oft mit kürzerer Kette. Die Auswahl ist ein Vertragsvergleich, kein Feature-Vergleich.

Was am Cluster überhaupt personenbezogen ist

Kubernetes speichert nicht "ein bisschen Metadaten". Personenbezug entsteht an konkreten Stellen:

• Workloads. Die Anwendung in den Pods: Kundendaten, Logs mit User-IDs, Support-Exporte.
• etcd und Secrets. Verbindungstrings, Tokens, manchmal Klartext-PII in ConfigMaps, weil es schneller ging.
• Logs und Traces. Ingress-Logs mit IP-Adressen und Pfaden, die eine Person identifizieren.
• Backups. Dieselben Daten, nur außerhalb des Clusters und oft länger aufbewahrt als die Live-Daten.
• Images und CI. Build-Logs, Registry-Accounts, Deploy-Identitäten.

Wer nur die Control Plane ansieht und die Logs vergisst, hat den größeren Speicher übersehen. Backup und Observability sind meist der eigentliche Drittland-Transfer, nicht der API-Server.

Fünf Kriterien, die der Vertrag hergeben muss

Ein Provider, der vier von fünf Punkten mündlich zusagt, ist kein DSGVO-Fokus. Er ist ein Vertriebsgespräch.

Hyperscaler oder Betreiber in Deutschland

AKS, EKS und GKE können in EU-Regionen laufen. Das löst den Standort der Nodes, nicht automatisch den der Support-Organisation, der Telemetrie und der Backups. Die AVV der Hyperscaler ist lang und deckt viel ab. Sie ist selten auf Ihren Namespace zugeschnitten.

Ein Managed-Kubernetes-Betreiber in Deutschland ist nicht automatisch besser. Er ist besser, wenn die Kette kürzer ist: ein Vertrag, ein Standort, Support, der nicht in ein Ticket-System in einem Drittland fällt. Schlechter ist er, wenn "Deutschland" nur der Vertrieb ist und die Nodes bei einem Hyperscaler ohne eigene AVV-Kette liegen.

Der Vergleich der Betriebskosten steht getrennt im Hosting-Kostenvergleich. Datenschutz ersetzt keine Rechnung, und eine günstige Rechnung ersetzt keinen AVV.

Für Finanzaufsicht reicht DSGVO nicht. DORA und BAIT sind ein eigener Prüfpfad: Kubernetes und BaFin.

Fragen, die vor der Unterschrift beantwortet sein müssen

1. In welcher Region laufen Nodes, etcd bzw. die gemanagte Control Plane, Backup-Ziele und das Log-Backend? Drei Antworten, nicht eine.
2. Wer kann im Supportfall kubectl auf unseren Cluster ausführen, und wird das protokolliert?
3. Liegt der AVV beim Kubernetes-Dienst oder nur beim darunterliegenden IaaS?
4. Welche Subunternehmer sehen Metadaten (IPs, Pod-Namen, Deploy-User)?
5. Können wir Manifeste, Persistent Volumes und Backups in 30 Tagen in einen anderen Cluster ziehen, ohne deren Operator?
6. Wie lange bleiben gelöschte Secrets und Volume-Snapshots wiederherstellbar?
7. Wo liegt das Ticketsystem?

Wer auf Frage 1 mit "Frankfurt" antwortet und auf Frage 3 ausweicht, hat den Vertrag nicht gelesen.

Was Sie selbst trotzdem tun müssen

Der Provider liefert die Plattform. Die TOMs in den Workloads bleiben bei Ihnen:

• NetworkPolicies, damit ein kompromittierter Pod nicht jede Datenbank erreicht. Startpunkt: Cluster absichern.
• RBAC ohne Wildcard auf Secrets. Startpunkt: RBAC-Audit.
• Logs ohne unnötige PII, Aufbewahrung mit Frist, nicht "wir löschen nie".
• Backup an einen Ort, der in derselben AVV-Kette liegt wie der Cluster. Backup ist ein Datenschutzthema, kein nur-Betriebsthema.

Ein Provider-Wechsel heilt keine ConfigMap mit Kundendaten.

Typische Fehlentscheidungen

• Siegel statt Standort. ISO 27001 beim Anbieter sagt nichts über die Region Ihrer Logs.
• Nur die Nodes ansehen. Der Drittland-Transfer sitzt im APM-Agenten, der "kurz zum Test" installiert wurde.
• Exit ignorieren. DSGVO verlangt auch, dass Sie die Verarbeitung beenden können. Ein Cluster, den nur deren CLI exportiert, können Sie nicht beenden.
• Managed mit Selbstbau-TOMs vermischen. Wenn der Betreiber die Control Plane patcht, stehen seine TOMs im Vertrag. Wenn Ihr Team die Nodes patcht, stehen sie in Ihrem Verzeichnis. Beides gleichzeitig "beim Provider" zu verbuchen, fällt im ersten Audit auf.

FAQ

Ist Kubernetes in der EU automatisch DSGVO-konform?

Nein. Die Region der Nodes ist eine Bedingung, nicht die Pflicht. AVV, Logs, Backups, Support-Zugriffe und Ihre eigene Workload-Konfiguration fehlen dann noch.

Reicht eine EU-Region bei AKS, EKS oder GKE?

Für den Node-Standort oft ja. Für Support, Telemetrie und Backup müssen Sie die jeweiligen Subunternehmer und Regionen lesen. "West Europe" auf dem Nodepool ist nicht die Antwort auf das Log-Backend.

Brauchen wir einen Anbieter mit Sitz in Deutschland?

Nicht zwingend. Sie brauchen eine nachvollziehbare Kette. Sitz in Deutschland verkürzt sie häufig, ersetzt aber nicht den AVV und nicht die Frage, wo die Nodes wirklich laufen.

Was prüfen wir in einem Architektur-Audit dazu?

Genau diese Grenzen: wo Daten liegen, wer zugreift, ob der Exit trägt. Der technische Ablauf steht im Architektur-Audit.

Welcher CTA ist der richtige, wenn wir nur vergleichen wollen?

Zuerst der Kostenvergleich und der Managed-vs-Inhouse-Vergleich. Der Vertrag kommt danach, nicht davor.

Fazit

Ein Kubernetes-Provider mit DSGVO-Fokus beantwortet Standort, AVV, TOMs, Subunternehmer und Exit schriftlich. Alles andere ist ein Rechenzentrum mit einem Datenschutz-Absatz. Die Pflicht in den Workloads bleibt bei Ihnen, unabhängig vom Logo auf der Rechnung.

Wenn die Kette unklar ist: Kontakt. Für die technische Härtung daneben: Security Quick-Check.