TL;DR

• 80% aller Kubernetes-Cluster haben mindestens eine kritische Compliance-Luecke -- die haeufigsten: fehlende Encryption at Rest, zu breite RBAC-Rollen und keine NetworkPolicies
• DSGVO Art. 32 verlangt "geeignete technische Massnahmen" -- in Kubernetes bedeutet das konkret: Verschluesselung, Zugriffskontrolle, Netzwerk-Segmentierung und Audit-Logging
• BSI IT-Grundschutz Bausteine APP.4.4 (Kubernetes) und CON.1 (Container) definieren 23 Anforderungen, von denen sich 17 technisch automatisieren lassen
• Eine strukturierte Gap-Analyse gegen BSI-Anforderungen dauert 2-3 Tage und deckt systematisch auf, wo Handlungsbedarf besteht
• Policy-as-Code mit Kyverno oder OPA Gatekeeper verhindert Compliance-Verstoesse, bevor sie entstehen

Kubernetes Compliance Luecken: DSGVO und BSI-Anforderungen richtig umsetzen

Kubernetes ist ein Framework, kein fertiges Produkt. Ein frisch installierter Cluster erfuellt weder die Anforderungen der DSGVO noch des BSI IT-Grundschutzes. Dieser Artikel zeigt die haeufigsten Compliance-Luecken, ordnet sie den konkreten DSGVO-Artikeln und BSI-Bausteinen zu und liefert technische Massnahmen zum Schliessen.

Die 7 haeufigsten Compliance-Luecken

Luecke 1: Keine Encryption at Rest fuer etcd

Was fehlt: etcd speichert alle Cluster-Daten -- einschliesslich Secrets, ConfigMaps und ServiceAccount-Tokens -- standardmaessig im Klartext. Wer Zugriff auf die etcd-Datenbank hat, liest alle Passwoerter und API-Keys.

DSGVO-Relevanz: Art. 32 Abs. 1 lit. a verlangt "Verschluesselung personenbezogener Daten". Wenn Secrets Datenbankzugangsdaten enthalten, die Zugriff auf personenbezogene Daten ermoeglichen, ist Encryption at Rest Pflicht.

BSI-Zuordnung: APP.4.4.A14 (Vertraulichkeit von etcd)

Massnahme:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    - configmaps
    providers:
    - aescbc:
        keys:
        - name: key1
          secret: BASE64_ENCODED_32_BYTE_KEY
    - identity: {}

Bei Managed Kubernetes (EKS, AKS, GKE) ist Encryption at Rest in der Regel aktiviert. Pruefen Sie Ihre Provider-Dokumentation -- "in der Regel" bedeutet nicht "garantiert".

Luecke 2: RBAC mit zu breiten Berechtigungen

Was fehlt: Teams vergeben cluster-admin aus Bequemlichkeit oder weil die initiale Einrichtung unter Zeitdruck erfolgte. Service Accounts haben oft mehr Rechte als noetig.

DSGVO-Relevanz: Art. 32 Abs. 1 lit. b verlangt die "Faehigkeit, die Vertraulichkeit [...] auf Dauer sicherzustellen". Zu breite RBAC-Rollen widersprechen dem Least-Privilege-Prinzip.

BSI-Zuordnung: ORP.4.A2 (Einrichtung, Aenderung und Entzug von Berechtigungen), APP.4.4.A7 (Trennung von Berechtigungen)

Audit-Befehl:

# Alle cluster-admin-Bindings auflisten
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | {name: .metadata.name, subjects: .subjects}'

# Service Accounts mit Secrets-Zugriff finden
kubectl auth can-i list secrets --all-namespaces --as=system:serviceaccount:default:default

Ziel-Zustand: Maximal 2-3 cluster-admin-Bindings (fuer den Cluster-Administrator und den CI/CD-Service-Account). Alle anderen Rollen auf Namespace-Ebene mit minimalen Rechten.

Fuer eine detaillierte Anleitung zur RBAC-Konfiguration siehe Kubernetes RBAC im Enterprise-Kontext.

Luecke 3: Fehlende NetworkPolicies

Was fehlt: Ohne NetworkPolicies kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren. Ein kompromittierter Container hat sofort Netzwerkzugriff auf alle Services, einschliesslich Datenbanken.

DSGVO-Relevanz: Art. 32 Abs. 1 lit. b -- Netzwerk-Segmentierung ist eine grundlegende technische Massnahme zur Sicherstellung der Vertraulichkeit.

BSI-Zuordnung: NET.1.1.A9 (Netzwerktrennung), APP.4.4.A10 (Absicherung der Container-Netzwerke)

Massnahme:

# Default-Deny als Ausgangsbasis
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Danach erlauben Sie gezielt nur die notwendigen Verbindungen. Dieser Ansatz ist aufwendiger als "alles offen", aber die einzige Methode, die vor Auditoren Bestand hat.

Luecke 4: Kein Audit Logging

Was fehlt: Kubernetes-Audit-Logging ist standardmaessig deaktiviert. Ohne Audit Logs koennen Sie nicht nachweisen, wer wann welche Aktion im Cluster durchgefuehrt hat.

DSGVO-Relevanz: Art. 5 Abs. 2 (Rechenschaftspflicht) und Art. 32 (Nachweis geeigneter Massnahmen). Ohne Audit-Trail koennen Sie bei einer Datenschutzverletzung nicht rekonstruieren, was passiert ist.

BSI-Zuordnung: DER.1.A3 (Protokollierung sicherheitsrelevanter Ereignisse), APP.4.4.A12 (Protokollierung)

Massnahme:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# Secrets-Zugriffe vollstaendig protokollieren
- level: RequestResponse
  resources:
  - group: ""
    resources: ["secrets"]
# Aenderungen an RBAC protokollieren
- level: RequestResponse
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]
# Alles andere auf Metadata-Ebene
- level: Metadata
  omitStages:
  - RequestReceived

Leiten Sie die Audit-Logs an ein zentrales SIEM weiter (Elasticsearch, Splunk, Azure Sentinel). Logs, die nur auf dem Node liegen, gehen bei einem Node-Ausfall verloren.

Fuer weitergehende Audit-Strategien empfehlen wir Kubernetes Security Audit.

Luecke 5: Container laufen als Root

Was fehlt: Viele Container-Images laufen standardmaessig als Root-User. Ein Angreifer, der eine Schwachstelle in der Anwendung ausnutzt, hat dann Root-Rechte im Container -- und mit der richtigen Privilege-Escalation auch auf dem Host.

BSI-Zuordnung: APP.4.4.A8 (Absicherung von Container-Images), CON.1.A5 (Minimale Rechte fuer Container)

Massnahme:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Das Restricted-Profil erzwingt: kein Root, kein privilegierter Modus, kein Zugriff auf Host-Namespaces, read-only Root-Filesystem und definierte Seccomp-Profile.

Fuer eine ausfuehrliche Anleitung zu Pod Security Standards siehe Kubernetes Pod Security Standards.

Luecke 6: Keine Image-Integritaetspruefung

Was fehlt: Ohne Image Signing und Verifikation koennen manipulierte Images in den Cluster gelangen. Supply-Chain-Angriffe ueber kompromittierte Base-Images oder Dependencies sind ein reales Risiko.

BSI-Zuordnung: CON.1.A7 (Integritaet von Container-Images), APP.4.4.A15 (Aktualitaet von Container-Images)

Massnahme mit Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-image-registry
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Images muessen aus der internen Registry stammen."
      pattern:
        spec:
          containers:
          - image: "registry.internal.company.com/*"

Ergaenzen Sie dies mit Cosign-Signaturpruefung und Vulnerability Scanning in der CI/CD-Pipeline. Fuer Scanning-Strategien siehe Kubernetes Security Scanning in unserem separaten Artikel.

Luecke 7: Fehlende Datenlokalisierung

Was fehlt: Bei Managed Kubernetes ist nicht immer klar, wo die Daten physisch gespeichert werden. etcd-Backups, Container-Logs und Monitoring-Daten koennen in Regionen ausserhalb der EU repliziert werden.

DSGVO-Relevanz: Art. 44-49 regeln die Uebermittlung personenbezogener Daten in Drittlaender. Wenn Cluster-Daten in US-Regionen repliziert werden, ist das ein DSGVO-Verstoss.

Massnahme:

• Cloud-Provider-Region auf EU beschraenken (eu-central-1, westeurope, europe-west3)
• Backup-Regionen explizit konfigurieren
• Log-Aggregation in EU-Region betreiben
• Container Registry in EU-Region hosten

BSI IT-Grundschutz Mapping fuer Kubernetes

Relevante Bausteine

Die folgende Tabelle zeigt die vollstaendige Zuordnung von BSI-Bausteinen zu Kubernetes-Massnahmen:

Automatisierung mit Policy-as-Code

Von den 23 relevanten BSI-Anforderungen lassen sich 17 technisch automatisieren. Der Schluessel ist Policy-as-Code -- Policies, die als Kubernetes-Ressourcen deployed werden und Verstoesse automatisch blockieren.

Implementierungsreihenfolge:

Phase 1 (Woche 1-2): Audit-Modus
├── Kyverno installieren
├── Policies im Audit-Modus deployen
├── Bestehende Verstoesse erfassen
└── Bericht fuer das Management erstellen

Phase 2 (Woche 3-4): Kritische Policies enforced
├── Pod Security Standards: Restricted
├── Image-Registry-Allowlist
├── Resource Limits erzwingen
└── Non-root-Container erzwingen

Phase 3 (Woche 5-6): Vollstaendige Abdeckung
├── NetworkPolicies fuer alle Namespaces
├── Audit Logging aktiviert und an SIEM angebunden
├── Encryption at Rest verifiziert
└── RBAC auf Least Privilege reduziert

DSGVO Art. 32: Technische Massnahmen in Kubernetes

Art. 32 DSGVO verlangt "geeignete technische und organisatorische Massnahmen". Die folgende Tabelle uebersetzt die vier Anforderungen aus Art. 32 Abs. 1 in konkrete Kubernetes-Konfigurationen:

Nachweispflicht nicht vergessen

DSGVO Art. 5 Abs. 2 verlangt, dass Sie die Einhaltung nachweisen koennen. In der Praxis bedeutet das:

• Audit-Logs aufbewahren (mindestens 12 Monate, je nach Branche laenger)
• Policy-Reports exportieren (Kyverno erzeugt PolicyReports als Kubernetes-Ressourcen)
• Regelmaessige Compliance-Scans dokumentieren (Trivy, kube-bench)
• Aenderungen an Security-Konfigurationen im Git nachvollziehbar halten (GitOps)

Audit-Vorbereitung: Praktische Schritte

Gap-Analyse durchfuehren (2-3 Tage)

Tag 1: Technischer Scan

# CIS Benchmark pruefen
kube-bench run --targets master,node

# RBAC-Analyse
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]'

# NetworkPolicies pruefen
kubectl get networkpolicies --all-namespaces

# Pod Security Standards pruefen
kubectl get namespaces -o json | \
  jq '.items[] | {name: .metadata.name, pss: .metadata.labels["pod-security.kubernetes.io/enforce"]}'

Tag 2: Dokumentations-Review

• Architektur-Dokumentation auf Aktualitaet pruefen
• RBAC-Konzept mit tatsaechlicher Konfiguration abgleichen
• Backup- und Recovery-Prozeduren verifizieren
• Incident-Response-Plan fuer Kubernetes-spezifische Szenarien pruefen

Tag 3: Bericht und Massnahmenplan

• Luecken priorisieren (kritisch, hoch, mittel, niedrig)
• Massnahmen mit Aufwand und Verantwortlichkeit definieren
• Zeitplan fuer die Umsetzung erstellen
• Management-Summary fuer die Geschaeftsfuehrung

Was Auditoren sehen wollen

Auditoren pruefen nicht Ihren Cluster direkt. Sie pruefen Dokumentation und Nachweise:

Haeufige Fragen

Reicht ein CIS Benchmark Scan fuer BSI-Konformitaet?

Nein. Der CIS Kubernetes Benchmark deckt circa 70% der technischen Anforderungen ab, aber nicht die organisatorischen: Rollen-Konzepte, Change-Management, Schulungen und Dokumentation. Nutzen Sie kube-bench als Ausgangspunkt und ergaenzen Sie die organisatorischen Massnahmen manuell.

Ist Managed Kubernetes automatisch DSGVO-konform?

Nein. Der Cloud-Provider sichert die Infrastruktur-Ebene (Shared Responsibility Model). Sie sind weiterhin verantwortlich fuer RBAC, NetworkPolicies, Secrets-Management und die Konfiguration Ihrer Workloads. "Managed" bedeutet nicht "compliant".

Wie oft sollte ich einen Compliance-Audit durchfuehren?

Automatisierte Checks bei jedem Deployment (via Admission Controller). Einen manuellen Review mindestens quartalsweise. Nach groesseren Aenderungen (Cluster-Upgrade, neue Namespaces, neue Teams) zusaetzlich. Der BSI empfiehlt eine jaehrliche Ueberpruefung des gesamten Sicherheitskonzepts.

Was kostet ein DSGVO-Verstoss?

Bis zu 20 Millionen EUR oder 4% des weltweiten Jahresumsatzes -- je nachdem, was hoeher ist. In der Praxis liegen Bussgelder typischerweise zwischen 10.000 und mehreren Millionen EUR, abhaengig von Schwere und Fahrlassigkeit. Die Reputationsschaeden sind oft teurer als das Bussgeld.

Brauche ich eine separate Compliance-Umgebung?

Nicht zwingend, aber empfohlen. Eine separate Staging-Umgebung, die die Produktions-Compliance-Konfiguration spiegelt, erlaubt es Ihnen, Policy-Aenderungen gefahrlos zu testen. Im Minimum sollten Sie einen Audit-Modus verwenden, bevor Sie Policies enforced.

Naechste Schritte

1. Sofort: Pruefen Sie, ob Encryption at Rest fuer etcd aktiviert ist
2. Diese Woche: Fuehren Sie einen RBAC-Audit durch (cluster-admin-Bindings zaehlen)
3. Diesen Monat: Installieren Sie Kyverno im Audit-Modus und erfassen Sie bestehende Verstoesse
4. Dieses Quartal: Fuehren Sie eine vollstaendige Gap-Analyse gegen BSI APP.4.4 durch
5. Fuer Unterstuetzung: Sprechen Sie uns an fuer eine strukturierte Compliance-Bewertung unter /kontakt

Fuer den Gesamtueberblick ueber DSGVO und BSI-Anforderungen in Kubernetes empfehlen wir unseren Kubernetes Security Hardening Guide.

Weiterfuehrende Artikel:

• Kubernetes Compliance: DSGVO und BSI
• Kubernetes Security Hardening
• Kubernetes Security Audit
• Kubernetes RBAC im Enterprise-Kontext
• Kubernetes Pod Security Standards

Compliance-Luecken in Kubernetes sind kein Schicksal -- sie sind Konfigurationsaufgaben. Wir unterstuetzen Sie bei der Gap-Analyse, Implementierung und Audit-Vorbereitung. Kontaktieren Sie uns unter /kontakt.