Compliance by Design: Kubernetes von Tag 1 DSGVO-, ISO-27001- und TISAX-konform betreiben

TL;DR

• Compliance by Design verankert regulatorische Anforderungen direkt in der Kubernetes-Plattform, statt sie nachtraeglich als Kontrolle aufzusetzen.
• Policy-as-Code mit Kyverno oder OPA Gatekeeper verhindert non-compliant Deployments bereits beim kubectl apply -- bevor sie in Produktion laufen.
• Die drei relevantesten Regelwerke fuer den deutschen Mittelstand -- DSGVO, ISO 27001 und TISAX -- lassen sich mit einem gemeinsamen Set von Kubernetes-Policies abdecken.
• Automatisierte Compliance-Reports ersetzen manuelle Checklisten und machen Audits reproduzierbar und stressfrei.
• Der Aufwand fuer nachtraegliche Compliance-Einarbeitung ist typischerweise 3-5x hoeher als die Integration ab Tag 1.

Warum Compliance nachtraeglich einbauen scheitert

In der Praxis sehen wir immer wieder dasselbe Muster: Ein Team baut einen Kubernetes-Cluster auf, deployt Anwendungen, skaliert erfolgreich -- und dann kommt der Auditor. Die Folge sind Wochen oder Monate Nacharbeit, um Compliance-Anforderungen nachtraeglich zu erfuellen.

Das Problem ist strukturell: Wenn Compliance nicht in der Plattform verankert ist, sondern als separate Kontrolle existiert, entstehen Luecken. Entwickler deployen Container mit Root-Rechten, weil es schneller geht. Sensible Daten landen in unverschluesselten ConfigMaps. Audit-Logs fehlen, weil niemand daran gedacht hat, sie von Anfang an zu aktivieren.

Compliance by Design dreht dieses Muster um: Die Plattform selbst stellt sicher, dass nur konforme Konfigurationen moeglich sind. Nicht-konforme Deployments werden automatisch blockiert, bevor sie den Cluster erreichen.

Die drei Regelwerke: Was DSGVO, ISO 27001 und TISAX von Kubernetes verlangen

DSGVO -- Datenschutz-Grundverordnung

Die DSGVO ist fuer jedes Unternehmen relevant, das personenbezogene Daten verarbeitet. Die zentralen Anforderungen, uebersetzt auf Kubernetes:

ISO 27001 -- Informationssicherheits-Managementsystem

ISO 27001 ist der internationale Standard fuer Informationssicherheit und wird haeufig von Geschaeftspartnern als Nachweis verlangt. Relevante Controls fuer Kubernetes:

TISAX -- Trusted Information Security Assessment Exchange

TISAX ist fuer Zulieferer in der Automobilindustrie praktisch Pflicht. Es basiert auf dem VDA ISA-Katalog und enthaelt zusaetzliche Anforderungen zu Prototypenschutz und Datensouveraenitaet.

Fuer Unternehmen in der Automobilindustrie empfehlen wir unseren Artikel Kubernetes Automotive: TISAX-Compliance.

Policy-as-Code: Compliance technisch erzwingen

Der Kern von Compliance by Design ist Policy-as-Code: Regulatorische Anforderungen werden als maschinenlesbare Regeln formuliert, die der Kubernetes Admission Controller bei jedem API-Request automatisch prueft.

Kyverno: Kubernetes-native Policies

Kyverno definiert Policies als Kubernetes-Ressourcen in YAML. Keine neue Sprache, kein Rego -- reines Kubernetes. Das senkt die Einstiegshuerde erheblich.

# Kyverno Policy: DSGVO Art. 25 + ISO 27001 A.8.2
# Erzwingt Non-Root-Container und Read-Only-Filesystem
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: compliance-baseline
  annotations:
    policies.kyverno.io/title: Compliance Baseline (DSGVO/ISO27001/TISAX)
    policies.kyverno.io/description: >-
      Erzwingt grundlegende Sicherheitsanforderungen fuer alle Pods:
      Non-Root, kein Privilege Escalation, Read-Only Root Filesystem.
      Deckt DSGVO Art. 25/32, ISO 27001 A.8.2/A.8.25 und TISAX ab.
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: require-non-root
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Container muessen als Non-Root laufen (DSGVO Art. 32, ISO 27001 A.8.2).
          Setzen Sie runAsNonRoot: true und eine runAsUser > 0.
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true
                  allowPrivilegeEscalation: false
    - name: require-readonly-rootfs
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Read-Only Root Filesystem ist Pflicht (ISO 27001 A.8.25).
          Setzen Sie readOnlyRootFilesystem: true.
        pattern:
          spec:
            containers:
              - securityContext:
                  readOnlyRootFilesystem: true
    - name: require-resource-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Resource Limits muessen gesetzt sein (ISO 27001 A.8.6).
          Definieren Sie CPU und Memory Limits fuer jeden Container.
        pattern:
          spec:
            containers:
              - resources:
                  limits:
                    memory: "?*"
                    cpu: "?*"

Wenn ein Entwickler einen Pod ohne runAsNonRoot: true deployen will, wird das Deployment sofort abgelehnt -- mit einer Fehlermeldung, die auf die relevante Compliance-Anforderung verweist.

OPA Gatekeeper: Flexible Constraint Templates

Fuer komplexere Anforderungen bietet OPA Gatekeeper mit der Sprache Rego maximale Flexibilitaet. Das folgende Beispiel erzwingt, dass alle Namespaces mit Compliance-relevanten Labels versehen sind:

# ConstraintTemplate: Pflicht-Labels fuer Compliance-Dokumentation
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: requiredlabels
spec:
  crd:
    spec:
      names:
        kind: RequiredLabels
      validation:
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package requiredlabels
        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Fehlende Pflicht-Labels: %v (TISAX/ISO 27001 Anforderung)", [missing])
        }
---
# Constraint: Alle Namespaces brauchen Compliance-Labels
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: RequiredLabels
metadata:
  name: namespace-compliance-labels
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels:
      - "compliance/data-classification"
      - "compliance/owner"
      - "compliance/retention-days"

Damit koennen keine Namespaces mehr ohne Datenklassifizierung, verantwortliche Stelle und Aufbewahrungsfrist erstellt werden -- genau das, was DSGVO Art. 30 (Verarbeitungsverzeichnis) und TISAX (Informationsklassifizierung) verlangen.

Mehr zur Toolauswahl fuer automatisierte Compliance lesen Sie in Kubernetes Compliance ohne Security-Team.

Automatisierte Audits: Vom manuellen Prozess zum Self-Service

Compliance-Reporting mit Policy Reports

Kyverno generiert automatisch PolicyReports, die den Compliance-Status jeder Ressource dokumentieren. Diese Reports koennen Sie fuer Auditoren exportieren:

# Alle Policy-Verstoesse im Cluster auflisten
kubectl get policyreport -A -o wide

# Detailbericht fuer einen Namespace
kubectl get policyreport -n produktion -o yaml

Audit-Checkliste automatisieren

Statt vor jedem Audit manuell Checklisten abzuarbeiten, definieren Sie die Pruefpunkte als Policies. Zur Audit-Vorbereitung generieren Sie dann automatisch den Nachweis:

Fuer die vollstaendige Security-Haertung empfehlen wir unseren Artikel Kubernetes Security Hardening: Die komplette Checkliste.

Compliance by Design in der Praxis: Architektur-Muster

Namespace-Strategie nach Datenklassifizierung

Statt Namespaces nur nach Teams oder Anwendungen zu organisieren, orientieren Sie die Struktur an der Datenklassifizierung:

cluster/
  namespaces/
    public/           # Oeffentliche Daten, minimale Einschraenkungen
    internal/         # Interne Daten, Standard-Policies
    confidential/     # Vertrauliche Daten, strenge Isolation
    restricted/       # Personenbezogene Daten (DSGVO), maximale Kontrolle

Jede Klassifizierungsstufe bekommt ein eigenes Policy-Set:

GitOps-Integration: Policies versioniert ausrollen

Compliance-Policies gehoeren in ein Git-Repository -- genau wie Anwendungscode. Mit ArgoCD oder Flux werden Aenderungen an Policies automatisch in den Cluster synchronisiert. Jede Aenderung ist versioniert, reviewt und nachvollziehbar.

Vorteile fuer den Audit:

• Versionierung: Wer hat wann welche Policy geaendert?
• Review-Prozess: Jede Aenderung durchlaeuft ein Pull-Request-Review
• Rollback: Fehlerhafte Policies koennen sofort zurueckgerollt werden
• Reproduzierbarkeit: Der Compliance-Status ist zu jedem Zeitpunkt nachvollziehbar

Fuer den Einstieg in GitOps empfehlen wir unseren Artikel ArgoCD GitOps fuer Kubernetes.

Typische Compliance-Luecken und wie Policies sie schliessen

Kosten-Nutzen: Compliance by Design vs. nachtraeglich

Fuer ein mittelstaendisches Unternehmen mit 5-10 Kubernetes-Clustern sieht die Rechnung typischerweise so aus:

Die hoehere initiale Investition amortisiert sich ab dem ersten Audit. Und sie skaliert: Wenn Sie einen neuen Cluster aufsetzen, wenden Sie das bestehende Policy-Set an, und Compliance ist ab Tag 1 gegeben.

Fazit: Compliance als Feature Ihrer Plattform

Compliance by Design bedeutet, regulatorische Anforderungen als Feature Ihrer Kubernetes-Plattform zu betrachten -- nicht als externe Auflage. Wenn Ihre Plattform es technisch unmoeglich macht, non-compliant zu deployen, verschwinden Compliance-Luecken und Audit-Stress.

Der Schluessel liegt in der Automatisierung: Policy-as-Code mit Kyverno oder OPA Gatekeeper, automatisierte Reports, GitOps-Integration und kontinuierliches Monitoring. Die initiale Investition ist ueberschaubar, und der Return on Investment zeigt sich bei jedem Audit, jedem neuen Cluster und jedem neuen Team.

Fuer Unternehmen, die ihre Kubernetes-Infrastruktur unabhaengig von Hyperscalern betreiben wollen, empfehlen wir unseren Artikel Kubernetes Private Cloud: Sovereign Cloud. Und wenn Sie die Cloud-Exit-Option als strategischen Hebel nutzen moechten, lesen Sie Vendor Lock-in vermeiden mit Kubernetes.

Weiterfuehrende Artikel

• Kubernetes DSGVO-Compliance: Checkliste -- Detaillierte regulatorische Anforderungen
• Kubernetes RBAC im Unternehmen -- Zugriffskontrolle richtig implementieren
• Kubernetes Security Hardening -- Technische Haertungs-Checkliste
• Kubernetes Compliance ohne Security-Team -- Automatisierung fuer kleine Teams
• Kubernetes Automotive TISAX -- Branchenspezifische Compliance