Kubernetes und DSGVO: Datenhaltung, Auftragsverarbeitung und Drittlandtransfer richtig regeln

Warum Kubernetes datenschutzrechtlich anders zu betrachten ist

Bei einem Managed Server ist meist klar, wo personenbezogene Daten liegen. In Kubernetes verteilen sie sich dagegen auf mehrere Ebenen: 

• Persistent Volumes für Datenbanken, Uploads und Sessions 
• etcd für Cluster-Zustand, ConfigMaps und Secrets 
• Logs und Monitoring-Systeme, die IP-Adressen oder Request-Daten erfassen 
• Caches und Queues wie Redis, RabbitMQ oder Kafka 
• Backups, Snapshots und CI/CD-Artefakte 

Da Pods neu erstellt, Nodes ausgetauscht und Replikas skaliert werden, entstehen zudem dynamische Datenkopien. Für ein Löschkonzept nach Art. 17 DSGVO muss daher klar sein, welche Daten nur flüchtig und welche dauerhaft gespeichert werden.

Datenhaltung: Wo Ihre personenbezogenen Daten tatsächlich liegen 

Datenhaltung: Wo Ihre personenbezogenen Daten tatsächlich liegen

Der erste Schritt ist immer eine ehrliche Bestandsaufnahme und erfahrungsgemäß tauchen dabei mindestens zwei Speicherorte auf, die im Verzeichnis von Verarbeitungstätigkeiten (Artikel 30 DSGVO) bisher nicht dokumentiert waren. Gehen Sie dafür Namespace für Namespace durch und beantworten Sie für jeden PersistentVolumeClaim, jede Datenbank und jeden externen Speicher drei Fragen: Welche Kategorien personenbezogener Daten liegen hier, auf welcher Rechtsgrundlage, und wie lange sollen sie aufbewahrt werden. Die Antworten gehören in das Verarbeitungsverzeichnis, nicht in ein Confluence-Dokument, das niemand pflegt.

Logs und Monitoring nicht unterschätzen

Der häufigste blinde Fleck. Ingress-Logs enthalten IP-Adressen und damit personenbezogene Daten. Application-Logs enthalten je nach Log-Level Session-IDs, E-Mail-Adressen oder komplette Request-Bodies. Tracing-Systeme speichern Query-Parameter, in denen bei ungünstiger Implementierung Kundennummern stehen. 

Praktische Maßnahmen: 

• Retention in Loki, Elasticsearch oder vergleichbaren Systemen bewusst setzen, nicht auf „unbegrenzt“ belassen 
• IP-Adressen im Ingress kürzen oder hashen, wo sie für den Betrieb nicht benötigt, werden 
• Log-Level in Produktion konsequent von Debug trennen 
• Personenbezogene Felder in Tracing-Span filtern, bevor sie das Cluster verlassen 

Löschkonzept auf Volume- und Backup-Ebene denken 

Ein Löschauftrag, der nur die Datenbankzeile entfernt, greift zu kurz, wenn dieselbe Information noch in drei Wochen alten Snapshots, im Log-Index und in einem Read-Replica liegt. Definieren Sie deshalb pro Datenkategorie eine Löschfrist über alle Ebenen hinweg inklusive Reclaim Policy der Volumes und Aufbewahrungsdauer der Backups. Dass Backups aus Gründen der Datensicherheit nicht sofort selektiv bereinigt werden können, ist rechtlich vertretbar, wenn Sie es dokumentieren und die Löschung mit dem Backup-Zyklus nachvollziehbar eintritt. 

Technische und organisatorische Maßnahmen nach Artikel 32 

Kubernetes bringt die Bausteine mit, aktiviert sie aber nicht von selbst. Zum Stand der Technik gehören heute: 

• RBAC mit dem Prinzip der geringsten Rechte, keine Cluster-Admin-Rollen für Entwickler-Accounts 
• Namespace-Trennung und Network Policies statt flacher Cluster-Netzwerke 
• Verschlüsselung der Secrets at rest in etcd sowie Transportverschlüsselung im Cluster 
• Pod Security Standards und Admission Control gegen privilegierte Container 
• regelmäßiges Image-Scanning und ein verlässlicher Patch-Prozess für Kubernetes selbst 
• nachvollziehbares Audit-Logging der Cluster-Zugriffe 

Diese Punkte sind nicht nur Sicherheitsthemen. Sie sind der Nachweis, den Sie im Ernstfall gegenüber einer Aufsichtsbehörde erbringen müssen.

Auftragsverarbeitung: Wer verantwortet was

Die Rollenverteilung ist im Grundsatz eindeutig: Sie als Shop- oder Plattformbetreiber sind Verantwortlicher im Sinne von Artikel 4 Nr. 7 DSGVO. Ihr Hosting- beziehungsweise Plattform-Anbieter ist Auftragsverarbeiter nach Artikel 28. Dafür braucht es einen Auftragsverarbeitungsvertrag (AVV), der die Verarbeitung weisungsgebunden regelt. 

Interessant wird es bei der Frage, wo im Kubernetes-Stack die Grenze verläuft. 

Die Shared Responsibility im Cluster

Bei Managed Kubernetes betreibt der Anbieter typischerweise Control Plane, Nodes, Netzwerk, Storage-Layer und Plattform-Komponenten. Sie behalten die Hoheit über Workloads, Konfigurationen und Deployments und damit über die eigentliche Datenverarbeitung. Praktisch heißt das: 

• Der Anbieter verantwortet die Sicherheit der Plattform und dokumentiert seine TOMs. 
• Sie verantworten, welche Daten Ihre Anwendungen verarbeiten, wie lange, mit welchem Log-Level und in welchen Namespaces. 
• Beide Seiten müssen wissen, wer im Zweifel welche Löschung ausführt. 

Diese Aufteilung gehört ausdrücklich in den AVV und in die Leistungsbeschreibung. Formulierungen, die nur „Hosting“ nennen, reichen bei einer Container-Plattform nicht aus. 

Was ein belastbarer AVV abdecken muss

• Gegenstand, Art und Zweck der Verarbeitung sowie die Kategorien betroffener Personen 
• Weisungsbindung und dokumentierte Weisungswege 
• eine vollständige, benannte Liste der Unterauftragsverarbeiter samt Standorten 
• Regelungen zur Änderung dieser Liste mit Widerspruchsrecht (Artikel 28 Absatz 2) 
• Unterstützungspflichten bei Betroffenenrechten, Datenschutz-Folgenabschätzung und Meldepflichten 
• Meldeprozess für Datenschutzverletzungen innerhalb der 72-Stunden-Frist des Artikels 33 
• Kontroll- und Auditrechte, praktikabel ausgestaltet über Zertifikate und Prüfberichte 
• Löschung oder Rückgabe der Daten nach Vertragsende, inklusive Backups 

Die unterschätzte Frage: Wie viele Auftragsverarbeiter hat Ihr Cluster eigentlich?

Der Cluster-Anbieter ist selten der einzige Dienstleister. In einem typischen Kubernetes-Setup kommen schnell weitere hinzu: 

• externe Container Registries 
• Observability- und Error-Tracking-Dienste 
• Log-Shipping in eine externe Plattform 
• Managed-Datenbank- oder Suchdienste außerhalb des Clusters 
• CI/CD-Plattformen mit Zugriff auf Produktionsumgebungen 
• Mail-, SMS- und Payment-Provider, die aus den Workloads heraus angebunden sind 
• CDN und WAF vor dem Ingress 

Jeder dieser Dienste, der personenbezogene Daten in Ihrem Auftrag verarbeitet, braucht einen eigenen AVV und muss im Verarbeitungsverzeichnis stehen. In der Praxis entstehen hier die meisten Lücken, weil solche Komponenten oft von Entwicklerseite eingebunden werden schnell, pragmatisch und ohne dass die Rechtsabteilung davon erfährt. Ein regelmäßiger Abgleich zwischen Helm-Releases und Dienstleisterliste ist deshalb kein Formalismus, sondern echte Risikominimierung. 

Drittlandtransfer: Der Punkt, an dem es unübersichtlich wird 

Kapitel V der DSGVO (Art. 44 ff.) regelt die Übermittlung personenbezogener Daten in Drittländer. Dabei zählt nicht nur die Speicherung: Bereits der Zugriff aus einem Drittland kann als Übermittlung gelten. 

Auch der Serverstandort allein reicht nicht aus. Unterliegt ein Anbieter US-Recht, können etwa CLOUD Act oder FISA 702 relevant sein selbst bei Servern in Deutschland. Dieses Risiko muss bei der Transfer-Folgenabschätzung berücksichtigt werden.

Typische Drittland-Fallen im Kubernetes-Betrieb 

• Telemetrie in Default-Konfigurationen von Charts, Operatoren oder Sidecars 
• Error-Tracking und Session-Replay-Tools, die Nutzerinteraktionen an außereuropäische Endpunkte senden 
• Log-Aggregation in SaaS-Plattformen mit Verarbeitung außerhalb der EU 
• Support- und Managed-Service-Zugriffe durch Teams außerhalb Europas 
• lange, einseitig änderbare Unterauftragnehmerketten bei großen Cloud-Plattformen 

Der wirksamste Hebel ist meistens Reduktion: Je kürzer die Kette der beteiligten Dienstleister und je klarer der Verarbeitungsraum, desto weniger Aufwand entsteht bei Prüfungen, Kundenaudits und Ausschreibungen. 

Rechtsgrundlagen im Überblick 

• Für die USA existiert seit Juli 2023 ein Angemessenheitsbeschluss auf Basis des EU-US Data Privacy Framework. Er gilt nur für zertifizierte Unternehmen und wird politisch wie juristisch weiter beobachtet. Wer sich darauf stützt, sollte die Zertifizierung des konkreten Dienstleisters prüfen und den Status regelmäßig kontrollieren. 
• Für andere Drittländer ohne Angemessenheitsbeschluss kommen in der Regel Standardvertragsklauseln zum Einsatz, ergänzt um ein Transfer Impact Assessment und gegebenenfalls zusätzliche Schutzmaßnahmen. 
• Ausnahmen nach Artikel 49 sind für den laufenden Hosting-Betrieb keine tragfähige Grundlage. 

Praktische Umsetzung in acht Schritten 

1. Bestandsaufnahme aller Datenspeicher im Cluster, inklusive Logs, Caches und Backups 
2. Klassifizierung der Datenkategorien und Zuordnung zu Verarbeitungszwecken 
3. Aktualisierung des Verzeichnisses von Verarbeitungstätigkeiten 
4. Vollständige Liste aller eingebundenen Dienstleister und Abgleich mit vorhandenen AVVs 
5. Prüfung jedes Dienstleisters auf Verarbeitungsstandorte und Zugriffe aus Drittländern 
6. Definition von Retention- und Löschfristen pro Datenkategorie, technisch umgesetzt 
7. Dokumentation der TOMs auf Cluster-Ebene: RBAC, Network Policies, Verschlüsselung, Patch-Prozess 
8. Festlegung des Incident-Prozesses inklusive Meldewegen und 72-Stunden-Frist 

Diese Liste ist bewusst pragmatisch gehalten. Sie ersetzt keine rechtliche Beratung, deckt aber die Punkte ab, die in Audits und Sicherheitsfragebögen regelmäßig abgefragt werden.

Wie Kubernetes ONE die Compliance-Seite vereinfacht

Kubernetes ONE reduziert die Komplexität rund um die DSGVO: Daten und Workloads werden ausschließlich in Deutschland und in ISO-zertifizierten Rechenzentren verarbeitet und gespeichert. Dazu kommen ein deutscher Vertragspartner, ein AVV nach Art. 28 DSGVO und ein persönlicher Ansprechpartner. 

Technisch unterstützen unter anderem RBAC, Kundenisolation, Network Policies und regelmäßige Security-Patches die Compliance. 

Die Verantwortung bleibt klar geteilt: Wir betreiben und sichern die Plattform, Sie verantworten die Datenverarbeitung innerhalb Ihrer Anwendungen. 

Fazit 

Kubernetes und DSGVO schließen sich nicht aus im Gegenteil: Mit Namespace-Isolation, RBAC, Network Policies und sauberem Secrets-Management bringt die Plattform gute Voraussetzungen für nachweisbare technische und organisatorische Maßnahmen mit. Der Aufwand entsteht dort, wo Daten unbemerkt in Logs, Caches und externe Dienste fließen und wo Verarbeitungsorte unklar bleiben. 

Wer die Datenhaltung sauber inventarisiert, die Auftragsverarbeitung über den gesamten Stack hinweg regelt und Drittlandtransfers durch eine kurze, europäische Dienstleisterkette von vornherein vermeidet, spart sich in Audits und Ausschreibungen erheblichen Aufwand.