DSGVO und Kubernetes: Container-Datenschutz praktisch umsetzen

TL;DR

Kubernetes-Cluster verarbeiten personenbezogene Daten in Logs, Secrets und persistenten Volumes. Für DSGVO-Compliance brauchen Sie Verschlüsselung at Rest (etcd EncryptionConfiguration), Datenresidenz in EU-Regionen, Log-Anonymisierung und technische Prozesse für das Recht auf Löschung. Dieser Guide zeigt die konkrete Umsetzung mit kopierbaren YAML-Configs.

Personenbezogene Daten landen in Kubernetes-Clustern an Stellen, die viele Teams übersehen: in Container-Logs, in etcd-Secrets, in persistenten Volumes und sogar in Audit-Logs. Die DSGVO verlangt technische Maßnahmen für all diese Speicherorte. Hier ist die etcd-Verschlüsselung als erster Schritt:

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key-2026-q1
              secret: <base64-encoded-32-byte-key>
      - identity: {}

Diese Konfiguration verschlüsselt Secrets und ConfigMaps in etcd mit AES-CBC. Der identity-Provider als Fallback stellt sicher, dass bereits gespeicherte unverschlüsselte Daten weiterhin lesbar bleiben.

Datenresidenz: Workloads an EU-Regionen binden

Art. 44-49 DSGVO regeln die Übermittlung personenbezogener Daten in Drittländer. In Kubernetes stellen Sie Datenresidenz über Node Affinity und Topology Constraints sicher.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kundendaten-api
  namespace: produktion
spec:
  replicas: 3
  selector:
    matchLabels:
      app: kundendaten-api
  template:
    metadata:
      labels:
        app: kundendaten-api
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/region
                    operator: In
                    values:
                      - eu-central-1    # Frankfurt
                      - eu-west-1       # Irland
                      - europe-west3    # Frankfurt (GCP)
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: kundendaten-api

Damit werden Pods mit personenbezogenen Daten ausschließlich auf Nodes in EU-Regionen gescheduled. Bei Managed Kubernetes (EKS, AKS, GKE) wählen Sie zusätzlich den Cluster-Standort in Frankfurt oder einer anderen EU-Region.

Namespace-basierte Datenisolierung

Trennen Sie Workloads mit personenbezogenen Daten in dedizierte Namespaces. Das vereinfacht Audit, Zugriffssteuerung und die Durchsetzung von Datenschutz-Policies.

apiVersion: v1
kind: Namespace
metadata:
  name: pii-workloads
  labels:
    data-classification: personenbezogen
    dsgvo-relevant: "true"
    pod-security.kubernetes.io/enforce: restricted
---
# NetworkPolicy: PII-Namespace nur von autorisierten Services erreichbar
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pii-isolation
  namespace: pii-workloads
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              pii-access: "true"
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              pii-access: "true"

Nur Namespaces mit dem Label pii-access: "true" dürfen mit dem PII-Namespace kommunizieren. Alle anderen Zugriffe werden blockiert.

Log-Daten anonymisieren

Container-Logs enthalten häufig personenbezogene Daten: IP-Adressen, E-Mail-Adressen, Nutzernamen. Nach DSGVO Art. 5 Abs. 1c (Datenminimierung) dürfen Sie nur das Nötigste speichern.

Setzen Sie Log-Anonymisierung auf Infrastruktur-Ebene um, nicht in jeder einzelnen Anwendung. Fluentd mit einem Anonymisierungs-Plugin oder ein Vector-Transform erledigt das zentral:

# Fluentd ConfigMap für Log-Anonymisierung
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-config
  namespace: logging
data:
  fluent.conf: |
    <filter kubernetes.**>
      @type record_transformer
      enable_ruby true
      <record>
        log ${record["log"].gsub(/\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b/, '[EMAIL-REDACTED]').gsub(/\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b/, '[IP-REDACTED]')}
      </record>
    </filter>

Recht auf Löschung in containerisierten Anwendungen

Art. 17 DSGVO gibt Betroffenen das Recht auf Löschung ihrer Daten. In einer Microservice-Architektur auf Kubernetes ist das eine technische Herausforderung, weil Daten über mehrere Services und Speichersysteme verteilt sind.

Notwendige Maßnahmen:

1. Dateninventar erstellen: Dokumentieren Sie, welcher Service welche personenbezogenen Daten in welchem PersistentVolume oder welcher Datenbank speichert.
2. Lösch-API pro Service: Jeder Microservice muss einen Endpunkt zur Datenlöschung bereitstellen.
3. Choreographie statt Orchestrierung: Nutzen Sie Events (z.B. über Kafka oder NATS), um Löschanfragen an alle betroffenen Services zu propagieren.
4. Backup-Rotation: Stellen Sie sicher, dass Backups nach definierter Frist rotieren -- gelöschte Daten dürfen nicht unbegrenzt in Backups existieren.

Audit-Logging für DSGVO-Nachweispflicht

Art. 5 Abs. 2 DSGVO verlangt Rechenschaftspflicht. Sie müssen nachweisen können, wer wann auf personenbezogene Daten zugegriffen hat. Kubernetes Audit-Logging liefert diese Nachweise.

# Audit Policy: Zugriffe auf PII-Namespaces vollständig protokollieren
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: RequestResponse
    namespaces: ['pii-workloads']
    resources:
      - group: ''
        resources: ['pods', 'secrets', 'configmaps', 'persistentvolumeclaims']
    omitStages:
      - RequestReceived
  - level: Metadata
    resources:
      - group: ''
        resources: ['pods/log']

FAQ

Reicht die etcd-Verschlüsselung für DSGVO-Compliance?

Nein. etcd-Verschlüsselung schützt Daten at Rest im Cluster-Speicher. Sie brauchen zusätzlich Verschlüsselung in Transit (mTLS), Zugriffskontrollen (RBAC) und organisatorische Maßnahmen. Die Verschlüsselung ist ein Baustein, nicht die komplette Lösung.

Wie stelle ich sicher, dass Pods nicht außerhalb der EU laufen?

Verwenden Sie Node Affinity mit requiredDuringSchedulingIgnoredDuringExecution und beschränken Sie die Regionen auf EU-Standorte. Bei Managed Kubernetes erstellen Sie den Cluster selbst in einer EU-Region. Ergänzend können OPA/Kyverno-Policies verhindern, dass Deployments ohne Region-Constraint erstellt werden.

Müssen Container-Logs nach DSGVO anonymisiert werden?

Ja, wenn sie personenbezogene Daten enthalten. IP-Adressen gelten nach EuGH-Rechtsprechung als personenbezogene Daten. Anonymisieren Sie Logs zentral über Fluentd oder Vector, bevor sie in ein Log-Management-System fließen.

Wie setze ich das Recht auf Löschung in Microservices um?

Implementieren Sie pro Service einen Lösch-Endpunkt und propagieren Sie Löschanfragen über ein Event-System (Kafka, NATS). Erstellen Sie ein Dateninventar, das dokumentiert, welcher Service welche personenbezogenen Daten speichert. Vergessen Sie Backups nicht -- diese müssen nach definierter Frist rotieren.