Kubernetes Data Sovereignty: Datensouveraenitaet fuer deutsche Unternehmen sicherstellen

TL;DR

• Data Sovereignty (Datensouveraenitaet) bedeutet die vollstaendige Kontrolle darueber, wo Daten gespeichert, verarbeitet und uebertragen werden -- ein zentrales Thema fuer DSGVO-Konformitaet.
• Node Affinity und Taints/Tolerations stellen technisch sicher, dass Workloads mit personenbezogenen Daten nur auf Nodes in deutschen oder EU-Rechenzentren laufen.
• Deutsche und EU-souveraene Cloud-Anbieter (IONOS, STACKIT, OVHcloud, Open Telekom Cloud) bieten Kubernetes-Services, bei denen Daten garantiert in Deutschland bleiben.
• Kyverno-Policies koennen erzwingen, dass Pods mit bestimmten Datenklassifizierungen nur auf zugelassenen Nodes gescheduled werden.
• Die Kombination aus technischen Kontrollen (Node Affinity), organisatorischen Massnahmen (Datenklassifizierung) und juristischen Absicherungen (AVV) schafft belastbare Datensouveraenitaet.

Warum Datensouveraenitaet fuer deutsche Unternehmen nicht verhandelbar ist

Die DSGVO stellt klare Anforderungen an die Verarbeitung personenbezogener Daten. Seit dem Schrems-II-Urteil des EuGH ist der Transfer personenbezogener Daten in die USA rechtlich problematisch -- auch wenn der EU-US Data Privacy Framework eine neue Grundlage geschaffen hat, bleibt die Rechtslage fragil.

Fuer deutsche Unternehmen, besonders im Mittelstand, bedeutet das:

• Personenbezogene Daten muessen nachweisbar in der EU/EWR verarbeitet werden
• Auftragsverarbeitungsvertraege (AVV) nach Art. 28 DSGVO muessen den Datenstandort regeln
• Branchenspezifische Anforderungen (TISAX, BAIT, KRITIS) verlangen haeufig Datenverarbeitung in Deutschland
• Geschaeftspartner und Kunden fordern zunehmend Nachweise ueber Datenlokalisierung
• Der CLOUD Act der USA kann US-Unternehmen (einschliesslich AWS, Azure, GCP) zur Herausgabe von Daten verpflichten -- unabhaengig vom Speicherort

In Kubernetes ist Datensouveraenitaet kein Automatismus. Ohne explizite Konfiguration kann der Scheduler Pods auf beliebigen Nodes platzieren -- auch in Regionen ausserhalb Deutschlands oder der EU.

Rechtsrahmen: Was DSGVO und nationale Gesetze konkret verlangen

Fuer eine vollstaendige Uebersicht der Compliance-Anforderungen empfehlen wir unseren Artikel Kubernetes DSGVO-Compliance: Checkliste fuer deutsche Unternehmen.

Cloud-Regionen: Wo Ihre Daten wirklich liegen

Hyperscaler mit deutschen Regionen

Die grossen Cloud-Anbieter betreiben Rechenzentren in Deutschland. Aber: Die Muttergesellschaften unterliegen dem US CLOUD Act.

Souveraene Cloud-Anbieter in Deutschland/EU

Fuer Unternehmen, die maximale Datensouveraenitaet benoetigen, ist die Kombination aus souveraenem Cloud-Anbieter und Kubernetes die beste Option. Details dazu finden Sie in unserem Artikel Kubernetes Private Cloud: Sovereign Cloud fuer deutsche Unternehmen.

Technische Umsetzung: Node Affinity fuer Datenlokalisierung

Nodes mit Regions-Labels versehen

Kubernetes-Nodes tragen standardmaessig Labels fuer Topologie-Informationen. Fuer Datenlokalisierung nutzen Sie diese Labels oder erstellen eigene:

# Standard-Labels (automatisch durch Cloud-Provider gesetzt)
# topology.kubernetes.io/region: eu-central-1
# topology.kubernetes.io/zone: eu-central-1a

# Eigene Labels fuer Datensouveraenitaet
kubectl label node worker-de-01 \
  sovereignty/country=de \
  sovereignty/data-classification=restricted \
  sovereignty/provider=ionos \
  sovereignty/compliance="dsgvo,iso27001"

Node Affinity: Workloads an deutsche Nodes binden

Mit nodeAffinity stellen Sie sicher, dass Pods nur auf Nodes in bestimmten Regionen gescheduled werden:

# Deployment mit Node Affinity fuer deutsche Rechenzentren
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kundendaten-service
  namespace: restricted
  labels:
    app: kundendaten-service
    compliance/data-classification: restricted
    compliance/regulation: dsgvo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kundendaten-service
  template:
    metadata:
      labels:
        app: kundendaten-service
        compliance/data-classification: restricted
    spec:
      # Node Affinity: Nur auf deutschen Nodes
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/region
                    operator: In
                    values:
                      - eu-central-1    # AWS Frankfurt
                      - germanywestcentral  # Azure Frankfurt
                      - europe-west3    # GCP Frankfurt
                  - key: sovereignty/country
                    operator: In
                    values:
                      - de
      # Topology Spread: Verteilung ueber Availability Zones
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: kundendaten-service
      containers:
        - name: kundendaten-service
          image: registry.internal.de/kundendaten-service:v2.1.0
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"

Die requiredDuringSchedulingIgnoredDuringExecution-Regel ist hier entscheidend: Sie stellt sicher, dass der Pod nie auf einem Node ausserhalb der angegebenen Regionen gestartet wird. Wenn keine passenden Nodes verfuegbar sind, bleibt der Pod im Status Pending, statt auf einem non-compliant Node zu laufen.

Taints und Tolerations: Dedizierte Nodes fuer sensible Daten

Fuer maximale Isolation koennen Sie Nodes mit Taints versehen, sodass nur explizit autorisierte Pods darauf gescheduled werden:

# Node mit Taint fuer sensible Daten versehen
kubectl taint nodes worker-de-restricted-01 \
  sovereignty/restricted=true:NoSchedule

# Pod mit passender Toleration
apiVersion: v1
kind: Pod
metadata:
  name: dsgvo-workload
  namespace: restricted
spec:
  tolerations:
    - key: "sovereignty/restricted"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"
  nodeSelector:
    sovereignty/country: de
    sovereignty/data-classification: restricted
  containers:
    - name: app
      image: registry.internal.de/dsgvo-app:v1.0.0

Policy-as-Code: Datenlokalisierung automatisch erzwingen

Manuelle Konfiguration allein reicht nicht. Entwickler koennten vergessen, Node Affinity zu setzen, oder absichtlich darauf verzichten, um Scheduling-Probleme zu umgehen. Mit Kyverno erzwingen Sie die Datenlokalisierung automatisch:

# Kyverno Policy: Erzwingt Node Affinity fuer restricted Workloads
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-data-sovereignty
  annotations:
    policies.kyverno.io/title: Data Sovereignty Enforcement
    policies.kyverno.io/description: >-
      Stellt sicher, dass Pods mit dem Label
      compliance/data-classification=restricted nur auf Nodes
      in deutschen Regionen gescheduled werden.
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-german-node-affinity
      match:
        any:
          - resources:
              kinds:
                - Pod
              selector:
                matchLabels:
                  compliance/data-classification: restricted
      validate:
        message: >-
          Pods mit Datenklassifizierung 'restricted' muessen eine
          Node Affinity fuer deutsche Regionen (sovereignty/country=de)
          enthalten. DSGVO Art. 44-49 erfordert Datenlokalisierung
          in der EU/EWR.
        pattern:
          spec:
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                    - matchExpressions:
                        - key: sovereignty/country
                          operator: In
                          values:
                            - de
    - name: require-data-classification-label
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaceSelector:
                matchLabels:
                  compliance/scope: dsgvo
      validate:
        message: >-
          Alle Pods in DSGVO-relevanten Namespaces muessen ein
          Label 'compliance/data-classification' tragen.
        pattern:
          metadata:
            labels:
              compliance/data-classification: "?*"

Diese Policy stellt zwei Dinge sicher:

1. Jeder Pod mit dem Label compliance/data-classification: restricted muss eine Node Affinity fuer deutsche Nodes haben.
2. Jeder Pod in einem DSGVO-relevanten Namespace muss ein Datenklassifizierungs-Label tragen.

Mehr zu Policy-as-Code und automatisierter Compliance finden Sie in unserem Artikel Kubernetes Compliance ohne Security-Team.

Persistent Volumes: Datenspeicherung lokalisieren

Node Affinity allein reicht nicht. Wenn Ihre Anwendungen Persistent Volumes (PVs) nutzen, muessen Sie sicherstellen, dass auch die Storage-Backends in deutschen Rechenzentren liegen.

StorageClass mit Zonen-Einschraenkung

# StorageClass: Nur Storage in deutschen AZs
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sovereign-storage-de
  labels:
    sovereignty/country: de
provisioner: ebs.csi.aws.com   # oder csi.ionos.com, etc.
parameters:
  type: gp3
  encrypted: "true"
allowedTopologies:
  - matchLabelExpressions:
      - key: topology.kubernetes.io/region
        values:
          - eu-central-1
      - key: topology.kubernetes.io/zone
        values:
          - eu-central-1a
          - eu-central-1b
          - eu-central-1c
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Retain

Der volumeBindingMode: WaitForFirstConsumer stellt sicher, dass das Volume erst provisioniert wird, wenn ein Pod es anfordert -- und zwar in derselben Zone wie der Pod. Zusammen mit Node Affinity ergibt sich eine durchgaengige Datenlokalisierung.

Netzwerk-Kontrollen: Daten im Land halten

Datensouveraenitaet betrifft nicht nur den Speicherort, sondern auch den Datenfluss. Sensible Daten duerfen nicht ueber Netzwerke ausserhalb Deutschlands oder der EU transportiert werden. Setzen Sie Default-Deny NetworkPolicies ein und erlauben Sie Egress nur zu definierten internen Zielen und ueber kontrollierte Egress-Gateways.

Fuer die vollstaendige Kontrolle des ausgehenden Traffics empfehlen wir unseren Artikel Kubernetes Egress Filtering.

Datenklassifizierung: Die Grundlage fuer alles

Bevor Sie technische Kontrollen implementieren, muessen Sie wissen, welche Daten wo verarbeitet werden. Eine Datenklassifizierung ist die Voraussetzung fuer wirksame Datensouveraenitaet.

Diese Klassifizierung uebersetzen Sie in Kubernetes-Labels und Namespace-Annotationen:

# Namespace fuer restricted Daten
apiVersion: v1
kind: Namespace
metadata:
  name: restricted
  labels:
    compliance/data-classification: restricted
    compliance/scope: dsgvo
    compliance/owner: datenschutzbeauftragter
    compliance/retention-days: "365"
    sovereignty/country: de

Multi-Cluster-Strategie fuer Datensouveraenitaet

Fuer maximale Isolation betreiben einige Unternehmen separate Cluster fuer unterschiedliche Datenklassifizierungen:

Dieser Ansatz ist aufwaendiger, bietet aber physische Trennung der Datenklassifizierungen und einfachere Auditierung. Fuer die Strategie zur Vermeidung von Cloud-Abhaengigkeit lesen Sie unseren Artikel Cloud Vendor Lock-in vermeiden mit Kubernetes.

Checkliste: Datensouveraenitaet in Kubernetes

Fazit: Datensouveraenitaet ist machbar -- mit den richtigen Kontrollen

Datensouveraenitaet in Kubernetes erfordert bewusstes Design. Die Kombination aus Node Affinity, lokalisierten StorageClasses, NetworkPolicies und Policy-as-Code schafft eine belastbare Grundlage. Souveraene Anbieter wie IONOS, STACKIT oder die Open Telekom Cloud eliminieren das CLOUD-Act-Risiko und vereinfachen die DSGVO-Argumentation.

Beginnen Sie mit der Datenklassifizierung, implementieren Sie Node Affinity und Kyverno-Policies, und dokumentieren Sie alles: Datensouveraenitaet muss nicht nur technisch umgesetzt, sondern auch nachgewiesen werden koennen.

Weiterfuehrende Artikel

• Kubernetes Private Cloud: Sovereign Cloud -- Souveraene Infrastruktur aufbauen
• Kubernetes DSGVO-Compliance: Checkliste -- Regulatorische Anforderungen im Detail
• Kubernetes Security Hardening -- Cluster-Haertung Schritt fuer Schritt
• Cloud Vendor Lock-in vermeiden -- Cloud-Exit-Strategie mit Kubernetes
• Kubernetes RBAC im Unternehmen -- Zugriffskontrolle implementieren