SIEM und SOAR in Kubernetes-Clustern: Praxisleitfaden fuer Security-Teams

TL;DR

• Kubernetes erzeugt Logs auf vielen Ebenen (API-Audit, Container-Stdout, Kubelet, etcd) -- ohne zentrale Aggregation fehlt jede Angriffserkennung
• Falco als Runtime-Security-Sensor kombiniert mit Fluent Bit als Log-Shipper bildet eine solide Open-Source-Basis fuer SIEM-Anbindung
• SOAR-Playbooks koennen kompromittierte Pods automatisch isolieren, indem sie NetworkPolicies oder Pod-Deletions triggern
• Die Mean Time To Detect (MTTD) sinkt erfahrungsgemaess von Stunden auf Minuten, wenn Audit-Logs automatisiert korreliert werden
• Starten Sie mit Audit-Logging und einem einzelnen Detection-Use-Case, nicht mit dem Versuch, alles gleichzeitig abzudecken

Warum SIEM/SOAR in Kubernetes anders funktioniert als in klassischen Umgebungen

In einer traditionellen Infrastruktur hat man Server mit festen IP-Adressen, bekannten Hostnamen und relativ statischen Log-Quellen. Ein SIEM kann sich darauf verlassen, dass die Quelle "webserver01" morgen noch existiert. In Kubernetes ist das fundamental anders.

Pods sind ephemeral. Ein Container, der heute Logs liefert, existiert morgen moeglicherweise nicht mehr. IP-Adressen wechseln bei jedem Restart. Namespaces gruppieren Workloads logisch, aber ein einzelner Node kann Pods aus Dutzenden Namespaces hosten.

Das bedeutet: Die Log-Aggregation muss als DaemonSet auf Node-Ebene laufen, nicht als Agent pro Anwendung. Und die Korrelation im SIEM braucht Kubernetes-spezifische Metadaten (Pod-Name, Namespace, Node, Labels), nicht nur IP-Adressen.

Die drei Saeulender Datenerfassung

Fuer eine funktionale Sicherheitsueberwachung in Kubernetes brauchen Sie drei Datenquellen:

1. Kubernetes Audit Logs -- Das API-Server-Audit-Log zeichnet jeden Zugriff auf die Kubernetes-API auf. Wer hat wann welchen Pod erstellt? Wer hat RBAC-Rollen veraendert? Wer hat Secrets gelesen? Ohne dieses Log sind Sie blind fuer alle Kontrollfluss-Manipulationen.

2. Container Runtime Logs -- Die stdout/stderr-Ausgabe jedes Containers. Hier finden sich Anwendungsfehler, aber auch Hinweise auf Exploitation (z.B. unerwartete Shell-Aufrufe, verdaechtige Netzwerkverbindungen).

3. Runtime Security Events -- Tools wie Falco ueberwachen Syscalls auf Kernel-Ebene und erkennen, wenn ein Container etwas tut, was er nicht tun sollte (z.B. /etc/shadow lesen, Reverse Shells oeffnen, Binaries herunterladen).

Audit-Policy konfigurieren

Der API-Server loggt standardmaessig nichts oder nur sehr wenig. Sie muessen eine Audit-Policy definieren, die festlegt, welche Events mit welchem Detailgrad erfasst werden. Hier eine praxistaugliche Policy:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets und ConfigMaps: Metadata loggen, keine Inhalte
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets", "configmaps"]

  # RBAC-Aenderungen: Vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # Pod-Exec und Port-Forward: Vollstaendig loggen
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/portforward", "pods/attach"]

  # Alle anderen Schreiboperationen: Request loggen
  - level: Request
    verbs: ["create", "update", "patch", "delete"]

  # Lesezugriffe: Nur Metadata
  - level: Metadata
    verbs: ["get", "list", "watch"]

Diese Policy balanciert zwischen ausreichender Sichtbarkeit und vertretbarem Log-Volumen. Vermeiden Sie RequestResponse fuer alles -- das erzeugt enorme Datenmengen, insbesondere bei Secrets, deren Inhalte dann im Klartext im Log landen.

Fluent Bit als Log-Shipper

Fluent Bit ist deutlich ressourcenschonender als Fluentd und fuer die meisten Kubernetes-Setups die bessere Wahl. Als DaemonSet laeuft es auf jedem Node und sammelt Container-Logs aus dem Dateisystem.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluent-bit
  namespace: logging
  labels:
    app.kubernetes.io/name: fluent-bit
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: fluent-bit
  template:
    metadata:
      labels:
        app.kubernetes.io/name: fluent-bit
    spec:
      serviceAccountName: fluent-bit
      tolerations:
        - operator: Exists
      containers:
        - name: fluent-bit
          image: fluent/fluent-bit:3.1
          resources:
            requests:
              cpu: 50m
              memory: 64Mi
            limits:
              cpu: 200m
              memory: 128Mi
          volumeMounts:
            - name: varlog
              mountPath: /var/log
              readOnly: true
            - name: containers
              mountPath: /var/lib/docker/containers
              readOnly: true
            - name: config
              mountPath: /fluent-bit/etc/
          env:
            - name: NODE_NAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
      volumes:
        - name: varlog
          hostPath:
            path: /var/log
        - name: containers
          hostPath:
            path: /var/lib/docker/containers
        - name: config
          configMap:
            name: fluent-bit-config

Der entscheidende Punkt: Setzen Sie readOnly: true auf die Volume-Mounts. Fluent Bit braucht keinen Schreibzugriff auf Host-Verzeichnisse. Definieren Sie Resource Limits -- ein unkontrollierter Log-Shipper kann einen Node destabilisieren, wenn das Log-Volumen explodiert.

Falco fuer Runtime-Erkennung

Falco operiert auf einer anderen Ebene als Log-Analyse. Es ueberwacht Syscalls ueber eBPF (oder das Kernel-Modul) und erkennt verdaechtiges Verhalten in Echtzeit. Ein paar Beispiele fuer Regeln, die in der Praxis relevant sind:

• Container startet eine Shell (/bin/bash, /bin/sh)
• Prozess liest sensitive Dateien (/etc/shadow, /etc/passwd)
• Outbound-Verbindung zu bekannten C2-Netzwerken
• Binaerdatei wird zur Laufzeit in einen Container geschrieben
• Namespace-Wechsel innerhalb eines Containers (Privilege Escalation)

Falco-Events koennen direkt an Ihren SIEM-Stack (Elasticsearch, Splunk, Wazuh) weitergeleitet werden. Der Output laesst sich als JSON konfigurieren, was die Weiterverarbeitung deutlich erleichtert.

SIEM-Architektur: Welches Backend?

Die Wahl des SIEM-Backends haengt von Ihrer bestehenden Infrastruktur ab. Hier ein Vergleich der gaengigen Optionen:

Fuer Teams, die bei Null anfangen, ist Wazuh oft der pragmatischste Einstieg: Open Source, bringt eigene Detection-Regeln mit und kann Kubernetes-Audit-Logs direkt konsumieren. Elastic SIEM bietet die bessere Visualisierung und Suchperformance, erfordert aber die kostenpflichtige Platinum-Lizenz fuer Security-Features.

SOAR: Automatisierte Incident Response

Der eigentliche Mehrwert von SOAR liegt nicht darin, dass es schneller Tickets erstellt. Der Mehrwert liegt in der automatisierten Eindaemmung (Containment), bevor ein Mensch ueberhaupt reagieren kann.

Ein konkretes Beispiel: Falco erkennt, dass ein Container in der Produktion eine Reverse Shell oeffnet. Das Event wird an das SIEM weitergeleitet, dort korreliert (ist der Pod auch in einem Namespace mit externem Netzwerkzugang?) und eine SOAR-Aktion wird getriggert:

#!/bin/bash
# soar-playbook: isolate-compromised-pod.sh
# Wird durch SOAR-Plattform bei Falco-Alert "Reverse Shell" getriggert

POD_NAME="$1"
NAMESPACE="$2"
TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

# 1. NetworkPolicy erstellen, die allen Traffic zum Pod blockiert
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-${POD_NAME}
  namespace: ${NAMESPACE}
  labels:
    security.kubernetes.io/isolation: "true"
    security.kubernetes.io/triggered-at: "${TIMESTAMP}"
spec:
  podSelector:
    matchLabels:
      app: $(kubectl get pod ${POD_NAME} -n ${NAMESPACE} -o jsonpath='{.metadata.labels.app}')
  policyTypes:
    - Ingress
    - Egress
EOF

# 2. Pod-Label setzen fuer forensische Markierung
kubectl label pod "${POD_NAME}" -n "${NAMESPACE}" \
  security.kubernetes.io/status=compromised \
  security.kubernetes.io/isolated-at="${TIMESTAMP}" \
  --overwrite

# 3. Memory-Dump erstellen, bevor der Pod geloescht wird (optional)
# kubectl exec ${POD_NAME} -n ${NAMESPACE} -- cat /proc/1/maps > /forensics/${POD_NAME}-maps.txt

# 4. Alert an Ops-Channel senden
echo "SECURITY ALERT: Pod ${POD_NAME} in ${NAMESPACE} wurde isoliert. Grund: Reverse Shell detected. Zeitpunkt: ${TIMESTAMP}"

Dieses Script ist bewusst einfach gehalten. In der Praxis wuerden Sie das in Ihrer SOAR-Plattform (z.B. Shuffle, Tines oder Splunk SOAR) als Workflow abbilden, mit Genehmigungsschritten und Eskalationspfaden.

Was Sie nicht automatisieren sollten

Automatische Pod-Deletion klingt verlockend, ist aber gefaehrlich. Wenn Falco einen False Positive meldet und Ihr SOAR-Playbook den Pod sofort loescht, haben Sie gerade Ihre Produktionsanwendung abgeschossen. Beginnen Sie mit:

1. Automatischer Isolation (NetworkPolicy) -- reversibel, kein Datenverlust
2. Automatischer Benachrichtigung -- Slack, PagerDuty, Ticket-System
3. Automatischer Forensik-Sicherung -- Logs und Metadaten exportieren

Erst wenn Sie ueber Wochen hinweg die False-Positive-Rate validiert haben, sollten Sie destruktive Aktionen wie Pod-Deletion automatisieren.

Typische Detection-Use-Cases

Statt zu versuchen, "alles" abzudecken, fokussieren Sie sich auf diese High-Value-Use-Cases:

Beginnen Sie mit einem einzigen Use Case, tunen Sie die Regeln, reduzieren Sie False Positives und erweitern Sie dann schrittweise.

Zusammenspiel mit bestehender Infrastruktur

SIEM/SOAR fuer Kubernetes existiert nicht im Vakuum. Sie muessen es in Ihre bestehende Security-Landschaft integrieren. Das bedeutet konkret:

• Monitoring-Stack: Wenn Sie bereits Prometheus und Grafana betreiben, nutzen Sie Alertmanager als zusaetzlichen Kanal fuer SIEM-relevante Metriken. Mehr dazu unter Kubernetes Observability Stack.
• Network Policies: Ohne Network Policies koennen Sie zwar Angriffe erkennen, aber nicht automatisiert eindaemmen. Eine solide Netzwerksegmentierung ist Voraussetzung. Siehe Network Policies im Detail.
• RBAC: Ihre Audit-Log-Analyse ist nur so gut wie Ihr RBAC-Setup. Wenn jeder cluster-admin hat, sind alle Audit-Events "normal". Grundlagen dazu finden Sie unter RBAC Enterprise Guide.
• Secret Management: Erkennung von Secret-Exfiltration setzt voraus, dass Secrets ueberhaupt sauber verwaltet werden. Empfehlung: Secrets Management mit Vault.

Sizing und Performance

Ein haeufiger Fehler: Das SIEM-Backend wird unterdimensioniert. Kubernetes-Cluster erzeugen erheblich mehr Log-Volumen als klassische Infrastrukturen, insbesondere wenn Audit-Logging aktiviert ist.

Faustregel fuer die Planung:

• Audit-Logs: 1-5 GB/Tag pro Cluster (abhaengig von der Policy und API-Aktivitaet)
• Container-Logs: Stark abhaengig von den Anwendungen, typisch 5-50 GB/Tag
• Falco-Events: Vergleichsweise gering, 100-500 MB/Tag

Planen Sie Retention-Zeiten realistisch. 30 Tage Hot Storage fuer Suche, 90 Tage Warm Storage fuer Compliance, und archivieren Sie danach in Cold Storage. Unbegrenzte Retention ist teuer und in den meisten Faellen nicht notwendig.

Schritt-fuer-Schritt-Einstieg

Wenn Sie heute noch kein SIEM/SOAR fuer Ihre Kubernetes-Cluster haben, empfehle ich diesen Weg:

Woche 1-2: Audit-Logging aktivieren. Die Policy von oben ist ein guter Startpunkt. Leiten Sie die Logs an eine zentrale Stelle weiter (Elasticsearch, Loki, oder einfach ein S3-Bucket als Zwischenloesung).

Woche 3-4: Fluent Bit als DaemonSet deployen. Container-Logs zentral aggregieren. Erste Dashboards in Grafana oder Kibana erstellen, um ein Gefuehl fuer "normal" zu bekommen.

Woche 5-6: Falco installieren. Standard-Regeln aktivieren und die Alerts beobachten. Sie werden viele False Positives sehen -- das ist normal. Tunen Sie die Regeln auf Ihre Workloads.

Woche 7-8: Ersten Detection-Use-Case im SIEM implementieren (z.B. "ClusterRoleBinding fuer cluster-admin erstellt"). Alerting einrichten.

Woche 9-12: SOAR-Automatisierung fuer den ersten Use Case. Beginnen Sie mit Isolation, nicht mit Deletion. Dokumentieren Sie den Runbook fuer manuelle Eskalation.

Haeufige Fehler

• Zu viel auf einmal: Lieber ein Use Case sauber implementiert als zehn halbgar
• Keine Baseline: Ohne zu wissen, was "normal" ist, erzeugt jede Anomalie-Erkennung nur Rauschen
• SIEM als Datenfriedhof: Wenn niemand die Alerts bearbeitet, bringt das beste SIEM nichts
• Fehlende Netzwerk-Segmentierung: SOAR kann nur isolieren, wenn NetworkPolicies greifen
• Audit-Logs ignorieren: Die meisten Teams deployen Monitoring, vergessen aber die API-Server-Audit-Logs komplett

Fazit

SIEM und SOAR in Kubernetes sind kein Projekt, das man einmal aufsetzt und dann vergisst. Es ist ein kontinuierlicher Prozess: Daten sammeln, Regeln schreiben, False Positives reduzieren, Automatisierung erweitern. Der Einstieg muss nicht teuer oder komplex sein -- Falco, Fluent Bit und Wazuh sind alle Open Source und production-ready.

Der wichtigste Schritt ist der erste: Schalten Sie Audit-Logging ein. Alles Weitere baut darauf auf.

Wenn Sie Unterstuetzung bei der Integration von SIEM/SOAR in Ihre Kubernetes-Infrastruktur benoetigen -- ob Architekturreview, Implementierung oder Tuning bestehender Regeln -- sprechen Sie uns an unter /kontakt.