Kubernetes Compliance automatisieren: Policy Engines und Scanner im Praxiseinsatz

TL;DR

• Policy Engines (Gatekeeper oder Kyverno) blockieren non-compliant Deployments direkt am API-Server
• Image-Scanner wie Trivy gehoeren in jede CI/CD-Pipeline -- am besten als Quality Gate vor dem Merge
• Startet im Audit-Modus, sammelt Daten fuer 2-4 Wochen, dann schrittweise auf Enforce umstellen
• kube-bench prueft eure Cluster-Konfiguration gegen CIS Benchmarks automatisiert
• Der gesamte Stack laesst sich mit Open-Source-Tools aufbauen -- kommerzielle Loesungen braucht ihr erst ab einer gewissen Clusteranzahl

Das Problem: Manuelle Compliance skaliert nicht

Wer Kubernetes-Cluster in Produktion betreibt, kennt das Szenario: Ein Audit steht an, und das Team verbringt Tage damit, Konfigurationen manuell gegen Checklisten abzugleichen. Screenshots werden erstellt, Tabellen befuellt, Abweichungen dokumentiert. Bei einem einzelnen Cluster ist das laestig, bei fuenf oder zehn wird es zum Vollzeitjob.

Das eigentliche Problem ist aber nicht der Zeitaufwand. Es ist die Tatsache, dass manuelle Checks immer nur Momentaufnahmen sind. Zwischen zwei Audits koennen Wochen vergehen, in denen non-compliant Deployments unbemerkt laufen. Ein vergessenes privileged: true, ein Container ohne Resource Limits, ein Image mit bekannten CVEs -- all das bleibt unsichtbar.

Automatisierung loest beide Probleme gleichzeitig: Sie prueft kontinuierlich und dokumentiert automatisch.

Architektur: Wo greifen die Tools ein?

Compliance-Automatisierung in Kubernetes laesst sich auf drei Ebenen implementieren:

Der entscheidende Punkt: Ihr braucht alle drei Ebenen. Nur CI/CD-Checks lassen sich umgehen (kubectl apply direkt). Nur Admission Control faengt keine bestehenden Ressourcen. Nur Runtime-Checks kommen zu spaet.

Kyverno vs. Gatekeeper: Welche Policy Engine passt?

Die zwei dominanten Policy Engines in der Kubernetes-Welt sind Kyverno und OPA Gatekeeper. Beide setzen am Admission Controller an, unterscheiden sich aber fundamental im Ansatz.

Meine Empfehlung: Fuer Teams, die noch keine Erfahrung mit Policy Engines haben, ist Kyverno der pragmatischere Einstieg. Die Policies sind reines YAML, das Debugging ist einfacher, und die Dokumentation ist hervorragend. Gatekeeper ist die bessere Wahl, wenn ihr bereits Rego-Erfahrung habt oder komplexe, organisationsweite Policies braucht.

Beispiel: Kyverno-Policy gegen privilegierte Container

Diese Policy blockiert alle Pods, die im privilegierten Modus laufen wollen:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
  annotations:
    policies.kyverno.io/title: Disallow Privileged Containers
    policies.kyverno.io/severity: high
spec:
  validationFailureAction: Audit   # erst Audit, spaeter auf Enforce
  background: true                  # prueft auch bestehende Ressourcen
  rules:
    - name: deny-privileged
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Privilegierte Container sind nicht erlaubt.
          Setze securityContext.privileged auf false.
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"
    - name: deny-privilege-escalation
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: >-
          Privilege Escalation ist nicht erlaubt.
        pattern:
          spec:
            containers:
              - securityContext:
                  allowPrivilegeEscalation: "false"

Der Wert validationFailureAction: Audit ist entscheidend fuer den Einstieg. Im Audit-Modus werden Verstoesse nur geloggt, nicht blockiert. So seht ihr, welche Workloads betroffen waeren, bevor ihr produktiven Traffic beeinflusst.

Mehr zu Security-Policies und wie sie in eine umfassende Absicherung passen, findet ihr im Artikel zu Kubernetes Runtime Security.

Trivy in der CI/CD-Pipeline

Trivy ist der De-facto-Standard fuer Container-Image-Scanning im Open-Source-Bereich. Es prueft auf CVEs, Fehlkonfigurationen und Secrets -- und laesst sich trivial in jede CI/CD-Pipeline einbinden.

Beispiel: GitLab CI mit Trivy als Quality Gate

stages:
  - build
  - scan
  - deploy

trivy-image-scan:
  stage: scan
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  variables:
    TRIVY_NO_PROGRESS: "true"
    TRIVY_CACHE_DIR: ".trivycache/"
  script:
    - trivy image
        --exit-code 1
        --severity HIGH,CRITICAL
        --ignore-unfixed
        --format table
        ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}
  cache:
    paths:
      - .trivycache/
  allow_failure: false  # Pipeline bricht bei HIGH/CRITICAL ab

trivy-config-scan:
  stage: scan
  image:
    name: aquasec/trivy:latest
    entrypoint: [""]
  script:
    - trivy config
        --exit-code 1
        --severity HIGH,CRITICAL
        ./k8s-manifests/
  allow_failure: false

Das Flag --exit-code 1 sorgt dafuer, dass die Pipeline fehlschlaegt, wenn Schwachstellen der angegebenen Severity gefunden werden. Mit --ignore-unfixed werden CVEs ohne verfuegbaren Fix ignoriert -- ein pragmatischer Kompromiss, der False Positives reduziert.

Wer die CI/CD-Integration weiter vertiefen will, findet im Artikel zu CI/CD im Enterprise-Umfeld weitere Patterns.

Cluster-Haertung mit kube-bench

kube-bench prueft eure Cluster-Konfiguration gegen die CIS Kubernetes Benchmarks. Das laesst sich als CronJob direkt im Cluster ausfuehren:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: kube-bench-scan
  namespace: security
spec:
  schedule: "0 3 * * 1"    # jeden Montag um 03:00
  jobTemplate:
    spec:
      template:
        spec:
          hostPID: true
          containers:
            - name: kube-bench
              image: aquasec/kube-bench:latest
              command: ["kube-bench", "run", "--json"]
              volumeMounts:
                - name: var-lib-etcd
                  mountPath: /var/lib/etcd
                  readOnly: true
                - name: etc-kubernetes
                  mountPath: /etc/kubernetes
                  readOnly: true
          restartPolicy: Never
          volumes:
            - name: var-lib-etcd
              hostPath:
                path: /var/lib/etcd
            - name: etc-kubernetes
              hostPath:
                path: /etc/kubernetes

Die Ergebnisse koennt ihr ueber einen Sidecar-Container an euer Monitoring-System weiterleiten. Fuer das Monitoring-Setup selbst gibt es eine ausfuehrliche Anleitung unter Kubernetes Observability Stack.

DSGVO und BSI C5: Was ist wirklich relevant?

Zwei Regelwerke tauchen in Compliance-Diskussionen rund um Kubernetes am haeufigsten auf: die DSGVO und der BSI C5-Katalog.

DSGVO-relevante Kubernetes-Konfigurationen:

• Data Residency: Pods, die personenbezogene Daten verarbeiten, muessen auf Nodes laufen, die in der EU stehen. Das laesst sich ueber Node Affinity und Taints/Tolerations durchsetzen.
• Access Control: RBAC-Konfigurationen muessen dem Need-to-know-Prinzip folgen. Kyverno kann pruefen, ob ClusterRoleBindings zu weitreichende Rechte vergeben.
• Audit Logging: Kubernetes Audit Logs muessen aktiviert, zentral gesammelt und revisionssicher gespeichert werden. Details dazu im Artikel zu Audit Logging.
• Verschluesselung: etcd-Daten muessen at rest verschluesselt sein, Service-zu-Service-Kommunikation sollte ueber mTLS laufen.

BSI C5 im Kubernetes-Kontext:

Der BSI C5-Katalog ist primaer fuer Cloud-Anbieter relevant, aber auch KMU, die Cloud-Dienste nutzen, profitieren davon, die Kriterien als Orientierung zu verwenden. Die relevantesten Bereiche fuer Kubernetes:

• Identitaets- und Rechtemanagement (IDM)
• Kryptografie und Schluesselmanagement (CRY)
• Protokollierung und Ueberwachung (LOG)
• Portabilitaet und Interoperabilitaet (PI)

Wer sich tiefer mit DSGVO-Konformitaet in Container-Umgebungen beschaeftigen will, findet im Artikel zu Cloud DSGVO und Kubernetes Compliance weitere Details.

Schrittweise Einfuehrung: Der pragmatische Weg

Compliance-Automatisierung ist kein Big-Bang-Projekt. Ein bewaehrter Ansatz in vier Phasen:

Phase 1 (Woche 1-2): Baseline erstellen

Installiert Trivy und kube-bench. Fuehrt erste Scans durch. Dokumentiert den Ist-Zustand. Das gibt euch eine Baseline, gegen die ihr spaeter messen koennt.

Phase 2 (Woche 3-4): Policy Engine im Audit-Modus

Installiert Kyverno (oder Gatekeeper). Startet mit 5-10 grundlegenden Policies im Audit-Modus: keine privilegierten Container, Resource Limits erforderlich, kein latest-Tag, readOnlyRootFilesystem. Beobachtet die Violations.

Phase 3 (Woche 5-8): CI/CD-Integration

Integriert Trivy als Quality Gate in eure Pipeline. Baut ein Dashboard (Grafana reicht) fuer Compliance-Metriken. Definiert Alerting-Regeln fuer kritische Violations.

Phase 4 (Woche 9-12): Enforce und erweitern

Stellt die wichtigsten Policies auf Enforce um. Erweitert den Policy-Satz schrittweise. Fuehrt eine interne Audit-Simulation durch. Plant die Integration von Falco fuer Runtime-Security.

Metriken, die zaehlen

Messt den Erfolg eurer Compliance-Automatisierung an diesen vier KPIs:

Die vierte Metrik ist besonders wichtig: Wenn eure Scans zu viele Builds blockieren, werden Entwickler anfangen, sie zu umgehen. Feinjustierung der Severity-Thresholds und gepflegte Ignore-Listen sind entscheidend fuer die Akzeptanz.

Haeufige Fehler

Zu viele Policies auf einmal. Startet mit 5-10, nicht mit 50. Teams brauchen Zeit, um ihre Workloads anzupassen.

Enforce ohne Audit-Phase. Wer direkt auf Enforce stellt, blockiert mit hoher Wahrscheinlichkeit produktive Deployments und verliert das Vertrauen der Entwicklerteams.

Scanner-Ergebnisse ignorieren. Ein Dashboard, das niemand anschaut, bringt keinen Compliance-Gewinn. Definiert klare Ownership fuer Findings.

Keine Exceptions. Nicht jede Policy passt auf jeden Workload. Baut einen Prozess fuer dokumentierte Ausnahmen ein (Kyverno unterstuetzt das nativ ueber exclude-Regeln).

Fazit

Compliance-Automatisierung in Kubernetes ist kein Luxus, sondern eine Notwendigkeit -- besonders wenn ihr BSI C5, DSGVO oder ISO 27001 einhalten muesst. Der Open-Source-Stack aus Kyverno/Gatekeeper, Trivy und kube-bench deckt die wesentlichen Anforderungen ab, ohne Lizenzkosten zu verursachen.

Der Schluessel zum Erfolg liegt nicht in den Tools, sondern im schrittweisen Vorgehen: Audit-Modus, Metriken sammeln, Teams schulen, dann erst enforced. Wer diesen Weg geht, spart pro Auditzyklus Dutzende Stunden und reduziert das Risiko von Compliance-Verstoessen drastisch.

Wenn ihr Unterstuetzung bei der Planung oder Implementierung eurer Compliance-Automatisierung braucht, meldet euch gerne fuer ein unverbindliches Gespraech unter /kontakt.