Kubernetes Compliance ohne Vollzeit-Security-Team: DSGVO und BSI in 30 Tagen

TL;DR

• DSGVO und BSI IT-Grundschutz lassen sich mit drei Open-Source-Tools automatisieren: Kyverno (Policies), Trivy (Scanning), kube-bench (CIS Benchmarks).
• Policy-as-Code ersetzt manuelle Checklisten und macht Compliance reproduzierbar und auditierbar.
• Ein mittelstaendisches Unternehmen braucht kein Vollzeit-Security-Team -- ein DevOps-Engineer mit den richtigen Tools reicht fuer den Einstieg.
• In 30 Tagen koennen Sie von Null auf einen auditierbaren Cluster kommen, wenn Sie systematisch vorgehen.
• Die Alternative -- Compliance ignorieren -- kostet im Ernstfall bis zu 4% des Jahresumsatzes (DSGVO) oder die Betriebserlaubnis (KRITIS).

Das Problem: Compliance-Anforderungen, aber kein Security-Budget

Sie kennen die Situation: Die Geschaeftsfuehrung will Kubernetes in Produktion, der Datenschutzbeauftragte fragt nach DSGVO-Konformitaet, und der BSI-Auditor steht im naechsten Quartal vor der Tuer. Ihr Team besteht aus zwei DevOps-Engineers, die bereits mit dem Tagesgeschaeft ausgelastet sind.

Ein dediziertes Security-Team? Dafuer fehlt das Budget. Ein externer CISO? Zu teuer fuer den Dauereinsatz. Also passiert, was in vielen Mittelstaendlern passiert: Compliance wird auf die lange Bank geschoben.

Das ist riskant. Die DSGVO sieht Bussgelder von bis zu 20 Millionen Euro oder 4% des Jahresumsatzes vor. BSI-Grundschutz-Zertifizierungen sind fuer KRITIS-Unternehmen Pflicht. Und seit der NIS2-Richtlinie fallen deutlich mehr Unternehmen unter verschaerfte Anforderungen.

Die gute Nachricht: Kubernetes Compliance ohne Security-Team ist machbar -- wenn Sie auf Automatisierung setzen.

Was DSGVO und BSI konkret von Ihrem Cluster verlangen

Bevor wir Tools installieren, muessen wir verstehen, was die Regulatoren eigentlich wollen. Hier die Kernanforderungen, uebersetzt auf Kubernetes:

Die vollstaendige Uebersicht finden Sie in unserem DSGVO-Compliance-Guide.

Der 30-Tage-Plan: Von Null auf auditierbar

Woche 1: Baseline Assessment mit kube-bench

Bevor Sie etwas aendern, brauchen Sie den Ist-Zustand. kube-bench prueft Ihren Cluster gegen den CIS Kubernetes Benchmark -- den De-facto-Standard, auf den sich auch das BSI bezieht.

# kube-bench als Job im Cluster ausfuehren
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ergebnisse anzeigen
kubectl logs job/kube-bench

# Oder als einmaligen Pod mit JSON-Output fuer spaetere Auswertung
kubectl run kube-bench --image=aquasecurity/kube-bench:latest \
  --restart=Never \
  --overrides='{
    "spec": {
      "hostPID": true,
      "containers": [{
        "name": "kube-bench",
        "image": "aquasecurity/kube-bench:latest",
        "command": ["kube-bench", "run", "--json"],
        "volumeMounts": [
          {"name": "var-lib-kubelet", "mountPath": "/var/lib/kubelet", "readOnly": true},
          {"name": "etc-kubernetes", "mountPath": "/etc/kubernetes", "readOnly": true}
        ]
      }],
      "volumes": [
        {"name": "var-lib-kubelet", "hostPath": {"path": "/var/lib/kubelet"}},
        {"name": "etc-kubernetes", "hostPath": {"path": "/etc/kubernetes"}}
      ]
    }
  }'

Typisches Ergebnis beim ersten Lauf: 40-60% der Checks schlagen fehl. Das klingt schlimm, ist aber normal. Viele Findings lassen sich mit wenigen Policy-Aenderungen beheben.

Dokumentieren Sie dieses Ergebnis. Es wird Ihre Baseline fuer den Auditor.

Woche 2: Policy-as-Code mit Kyverno

Kyverno ist der Schluessel zu Kubernetes Compliance ohne Security-Team. Statt manuell zu pruefen, ob Entwickler sichere Manifests schreiben, erzwingt Kyverno Regeln automatisch beim Deployment.

Warum Kyverno statt OPA Gatekeeper? Kyverno verwendet native Kubernetes-Syntax (kein Rego), ist leichter zu debuggen und hat eine flachere Lernkurve. Fuer ein Team ohne Security-Spezialisten ist das entscheidend.

# kyverno-baseline-policies.yaml
# Diese Policy erzwingt die wichtigsten DSGVO/BSI-Anforderungen
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: baseline-security-compliance
  annotations:
    policies.kyverno.io/title: Baseline Security Compliance
    policies.kyverno.io/description: >-
      Erzwingt grundlegende Sicherheitsanforderungen nach
      BSI IT-Grundschutz und DSGVO Art. 32
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    # BSI SYS.1.6 / DSGVO Art. 32: Keine Root-Container
    - name: deny-root-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Container duerfen nicht als Root laufen.
          Setzen Sie runAsNonRoot: true (BSI SYS.1.6)
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
    # BSI OPS.1.1.5: Resource Limits fuer Audit-Trail
    - name: require-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Alle Container muessen CPU/Memory Limits haben.
          Notwendig fuer Kapazitaetsplanung und Audit.
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"
    # DSGVO Art. 44-49: Datenlokation sicherstellen
    - name: require-node-selector-production
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - production
                - customer-data
      validate:
        message: >-
          Pods im Production-Namespace muessen auf EU-Nodes laufen.
          Setzen Sie nodeSelector oder nodeAffinity (DSGVO Art. 44).
        pattern:
          spec:
            nodeSelector:
              topology.kubernetes.io/region: "eu-*"

Installieren Sie Kyverno und die Policies schrittweise. Starten Sie mit validationFailureAction: Audit und wechseln Sie erst nach einer Woche auf Enforce, damit Sie bestehende Workloads nicht abwuergen.

Eine umfassende Einfuehrung in Policy-Automatisierung bietet unser Kyverno und OPA Tutorial.

Woche 3: Image Scanning mit Trivy

Jedes Container-Image, das in Ihrem Cluster laeuft, ist ein potenzielles Einfallstor. Trivy scannt Images auf bekannte CVEs, Fehlkonfigurationen und Secrets -- und laesst sich direkt in die CI/CD-Pipeline integrieren.

# trivy-scan-cronjob.yaml
# Taeglicher Scan aller laufenden Images im Cluster
apiVersion: batch/v1
kind: CronJob
metadata:
  name: trivy-cluster-scan
  namespace: security-tools
spec:
  schedule: "0 6 * * *"  # Jeden Morgen um 06:00
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: trivy-scanner
          containers:
            - name: trivy
              image: aquasecurity/trivy:latest
              command:
                - /bin/sh
                - -c
                - |
                  # Alle Running-Pods im Cluster scannen
                  kubectl get pods -A -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
                    | sort -u \
                    | while read image; do
                        echo "=== Scanning: $image ==="
                        trivy image --severity HIGH,CRITICAL \
                          --exit-code 0 \
                          --format table \
                          "$image"
                      done
              resources:
                limits:
                  cpu: "1"
                  memory: "2Gi"
                requests:
                  cpu: "500m"
                  memory: "1Gi"
          restartPolicy: OnFailure

Noch besser: Nutzen Sie den Trivy Operator, der als Admission Webhook fungiert und unsichere Images vor dem Deployment blockiert. In Kombination mit Kyverno koennen Sie Policies definieren wie "Kein Deployment mit CRITICAL CVEs in Production".

Woche 4: Audit-Logging und Dokumentation

Compliance ist nicht nur Technik -- es ist Nachweisfuehrung. Der Auditor will nicht Ihren Cluster sehen, sondern Ihre Dokumentation.

Aktivieren Sie Kubernetes Audit Logging:

# audit-policy.yaml -- fuer den API-Server
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Alle Aenderungen an Secrets loggen (DSGVO Art. 30)
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
    namespaces: ["production", "customer-data"]

  # RBAC-Aenderungen loggen (BSI ORP.4)
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # Deployments und StatefulSets loggen
  - level: Metadata
    resources:
      - group: "apps"
        resources: ["deployments", "statefulsets", "daemonsets"]

  # Alles andere: nur Metadaten
  - level: Metadata
    omitStages:
      - RequestReceived

Erstellen Sie parallel eine Compliance-Dokumentation, die folgende Punkte abdeckt:

• Verzeichnis der Verarbeitungstaetigkeiten (Art. 30 DSGVO) fuer containerisierte Services
• Technisch-organisatorische Massnahmen (Art. 32 DSGVO) mit Verweis auf Kyverno-Policies
• Ergebnisse der kube-bench-Scans als Nachweis fuer BSI-Konformitaet
• Trivy-Reports als Nachweis fuer Schwachstellenmanagement

Tool-Vergleich: Was brauchen Sie wirklich?

Empfehlung fuer den Einstieg: Kyverno + Trivy + kube-bench. Diese drei Tools decken 80% der Anforderungen ab und sind in einer Woche produktiv einsetzbar. Falco kommt in Phase 2 dazu, wenn Sie Runtime-Monitoring brauchen.

Policy-as-Code: Warum das der Gamechanger ist

Der traditionelle Compliance-Ansatz funktioniert so: Ein Berater erstellt eine Checkliste, Ihr Team arbeitet sie ab, beim naechsten Audit ist die Haelfte veraltet. Das ist teuer, fehleranfaellig und nicht skalierbar.

Policy-as-Code dreht das Prinzip um:

Der entscheidende Vorteil fuer Teams ohne Security-Spezialisten: Einmal konfiguriert, wirkt es dauerhaft. Kein Entwickler kann versehentlich einen Root-Container deployen, wenn Kyverno das blockiert. Kein Image mit kritischen CVEs landet in Production, wenn Trivy im Admission-Webhook haengt.

Mehr zu RBAC und Zugriffskontrolle erfahren Sie im RBAC Enterprise Guide.

Haeufige Fehler beim Compliance-Einstieg

Fehler 1: Alles auf einmal erzwingen

Schalten Sie Kyverno nicht direkt auf Enforce fuer alle Policies. Starten Sie im Audit-Modus, analysieren Sie die Violations, und informieren Sie die Entwickler-Teams. Erst wenn die Quote unter 5% faellt, schalten Sie auf Enforce um. Sonst blockieren Sie die komplette Deployment-Pipeline am ersten Tag.

Fehler 2: Compliance als einmaliges Projekt behandeln

Compliance ist kein Zustand, sondern ein Prozess. Richten Sie einen woechentlichen CronJob ein, der kube-bench und Trivy ausfuehrt und die Ergebnisse an Ihr Monitoring sendet. So sehen Sie Regressionen sofort.

Fehler 3: Die Dokumentation vergessen

Tools allein reichen nicht. Der Auditor will sehen, dass Sie einen dokumentierten Prozess haben. Legen Sie ein Git-Repository fuer Ihre Compliance-Artefakte an: Policies, Scan-Reports, Massnahmenplaene. Git-Commits sind ein hervorragender Audit-Trail.

Fehler 4: BSI-Grundschutz woertlich umsetzen

Der BSI IT-Grundschutz ist fuer klassische IT geschrieben. Container und Kubernetes erfordern eine Interpretation der Bausteine. SYS.1.6 (Container) ist direkt anwendbar, andere Bausteine muessen sinnvoll uebersetzt werden. Im Zweifel hilft ein einmaliges Beratungsgespraech mehr als woechenlange Eigenrecherche.

Realistischer Aufwand und Kosten

30-Tage Compliance-Projekt (1 DevOps-Engineer, 50% Kapazitaet):

Woche 1: kube-bench + Baseline Assessment         ~20 Stunden
Woche 2: Kyverno Setup + Basis-Policies           ~20 Stunden
Woche 3: Trivy Integration + CI/CD-Pipeline        ~20 Stunden
Woche 4: Audit-Logging + Dokumentation             ~20 Stunden
─────────────────────────────────────────────────────────────
Gesamt:                                             ~80 Stunden
Kosten (interner Aufwand):                          ~4.000-6.000 EUR
Tool-Kosten:                                        0 EUR (Open Source)

Vergleich: Ein externer Compliance-Audit ohne Vorbereitung kostet 15.000-30.000 EUR und liefert eine Maengelliste, die Sie dann selbst abarbeiten muessen. Mit den 80 Stunden Vorbereitung reduzieren Sie den Audit-Aufwand auf ein Drittel.

Wenn Ihnen die internen Kapazitaeten fehlen, lohnt sich der Blick auf einen Managed Kubernetes Service, der Compliance-Anforderungen als Teil des Pakets abdeckt.

Wie es nach den 30 Tagen weitergeht

Die ersten 30 Tage decken die Grundlagen ab. Danach stehen zwei Themen an:

Continuous Compliance: Integrieren Sie Trivy in Ihre CI/CD-Pipeline (GitLab CI, GitHub Actions, ArgoCD). Jeder Pull Request wird automatisch auf Compliance geprueft, bevor er gemerged wird. Mehr dazu im GitOps Security Guide.

Erweitertes Monitoring: Falco ueberwacht das Laufzeitverhalten Ihrer Container. Wenn ein Prozess ploetzlich eine Shell oeffnet oder auf sensible Dateien zugreift, erhalten Sie sofort einen Alert. Das ist die Bruecke zwischen praevention (Kyverno) und Erkennung (Falco).

Fuer das Monitoring-Setup empfehlen wir unseren Observability Stack Guide.

Fazit

Kubernetes Compliance ohne Security-Team ist kein Wunschdenken, sondern eine Frage der richtigen Werkzeuge. Kyverno, Trivy und kube-bench sind Open Source, gut dokumentiert und in 30 Tagen produktiv einsetzbar.

Der Schluessel ist Policy-as-Code: Statt manueller Checklisten definieren Sie Ihre Compliance-Anforderungen als Kubernetes-Ressourcen. Das ist reproduzierbar, auditierbar und skaliert ohne zusaetzliches Personal.

Fangen Sie diese Woche mit kube-bench an. Der erste Scan dauert 10 Minuten und zeigt Ihnen sofort, wo Sie stehen. Von dort aus ist jeder weitere Schritt planbar.

Sie moechten Unterstuetzung bei der Umsetzung oder ein Review Ihrer bestehenden Compliance-Massnahmen? Wir begleiten Mittelstaendler von der Erstanalyse bis zum bestandenen Audit -- sprechen Sie uns an.