Wazuh auf EKS: Warum ein Filebeat.yml-VolumeMount den Manager crasht – und wie du Archives sauber aktivierst

von

Einleitung

Wer Wazuh in Kubernetes (z. B. EKS) betreibt, will früher oder später mehr als nur alerts.json in den Indexer schreiben: Für forensische Analysen, Incident Response und Compliance ist das Archiv-Logging (archives.json) extrem wertvoll. In klassischen Deployments genügt oft ein simples Aktivieren des Filebeat-Archives-Filesets. In Kubernetes kann genau dieser Schritt jedoch dazu führen, dass der Wazuh-Manager gar nicht mehr startet – scheinbar mit „ossec.conf“-Fehlern, tatsächlich aber durch Mount-Konflikte.

Ausgangslage / Problemstellung

Umgebung und Symptome im beschriebenen Setup:

  • Wazuh läuft auf EKS, Manager als StatefulSet (Master/Worker).
  • Ziel: Archives aktivieren über ein custom filebeat.yml.
  • Danach: Pods gehen in RunContainerError / BackOff.
  • Kubernetes Event zeigt klaren Mount-Fehler: error mounting ... to /etc/filebeat/filebeat.yml: ... not a directory
  • Sobald der volumeMount für /etc/filebeat/filebeat.yml entfernt wird, verschwinden auch Manager-Startfehler wie:
    • Could not open file 'etc/shared/ar.conf'
    • Configuration error at 'etc/ossec.conf'

Das wirkt auf den ersten Blick wie ein Wazuh-Konfigurationsproblem. Tatsächlich ist es ein Kubernetes-Volume-Mount-Problem, das Wazuh nur „sekundär“ trifft.

Technische Analyse

1) Root Cause: Kubernetes kann keine Datei in ein Verzeichnis mounten, das aus einem anderen Volume kommt

Im Container existiert bereits ein Mount:

- name: wazuh-manager-master
  mountPath: /etc/filebeat
  subPath: filebeat/etc/filebeat

Damit kommt das gesamte Verzeichnis /etc/filebeat aus dem Volume wazuh-manager-master.

Zusätzlich wird versucht, eine einzelne Datei aus einem anderen Volume in dieses Verzeichnis zu mounten:

- name: config
  mountPath: /etc/filebeat/filebeat.yml
  subPath: filebeat.yml

Das ist in Kubernetes ein klassischer Overlay-Konflikt:
Ein Pfad (/etc/filebeat) ist bereits durch ein Volume belegt. Eine einzelne Datei (/etc/filebeat/filebeat.yml) aus einem zweiten Volume „darüber“ zu legen, führt zu Inkonsistenzen – je nach Runtime endet das in Fehlern wie „not a directory“ oder fehlschlagenden init-Schritten.

2) Warum bricht danach Wazuh (analysisd) mit ossec.conf-Meldungen ab?

Durch den Mount-Konflikt startet der Container nicht „sauber“. Das Filesystem-Layout im Container ist nicht in dem Zustand, den die Entrypoints und s6-Services erwarten. Wazuh-Komponenten greifen dann auf Pfade zu, die (aus ihrer Sicht) fehlen oder nicht lesbar sind, z. B.:

  • etc/shared/ar.conf (relativ zu /var/ossec)
  • Folgemeldung „Configuration error at ‚etc/ossec.conf’“

Wichtig: In dem Thread wurde bestätigt, dass ossec.conf inhaltlich valide ist – die Fehler sind Side-Effects der Mount-Probleme.

3) Das gleiche Muster gilt für Rules/Decoders unter /var/ossec/etc/...

Wenn /var/ossec/etc bereits über ein Persistent Volume gemountet wird (wie im StatefulSet), erzeugt ein zusätzlicher Mount einzelner Dateien aus einem anderen Volume in genau dieses Verzeichnis denselben Konflikt. Das ist der Grund, warum „ich brauche noch Rules/Decoders“ in Kubernetes-Setups häufig nicht per „subPath Datei über PV-Verzeichnis“ gelöst werden kann, ohne in Konflikte zu laufen.

Lösung / Best Practices

Zielbild: Ein Pfad – ein Volume (pro Verzeichnisbaum)

Für /etc/filebeat bedeutet das:
Entweder mountest du das komplette Verzeichnis /etc/filebeat aus einer einzigen Quelle, oder du legst deine Custom-Datei an einen alternativen Pfad und lässt sie per Init/Entrypoint in den richtigen Ort kopieren. In Wazuh-Helm/Kustomize-Deployments ist der robusteste Weg:

Variante A (empfohlen): Eigenes ConfigMap-Volume für /etc/filebeat – und den alten /etc/filebeat-Mount entfernen

  1. Neues ConfigMap (z. B. wazuh-filebeat-conf) nur für Filebeat-Inhalte:

kustomization.yml

configMapGenerator:
  - name: wazuh-filebeat-conf
    files:
      - wazuh_managers/wazuh_conf/filebeat.yml
      # optional: template/json, module configs etc.
  1. StatefulSet Volume + Mount:
volumes:
  - name: wazuh-filebeat-conf
    configMap:
      name: wazuh-filebeat-conf

volumeMounts:
  - name: wazuh-filebeat-conf
    mountPath: /etc/filebeat
  1. Wichtig: Entferne die konfliktträchtigen Mounts:
  • Entfernen/kommentieren:
    • mountPath: /etc/filebeat aus wazuh-manager-master (PV)
    • mountPath: /etc/filebeat/filebeat.yml aus config (wazuh-conf)

Damit kommt /etc/filebeat vollständig aus einem Volume, und filebeat.yml wird zuverlässig verwendet.

Variante B: Custom filebeat.yml nicht nach /etc/filebeat mounten, sondern in einen separaten Pfad + Copy

Wenn du /etc/filebeat zwingend aus dem bestehenden Volume behalten musst (z. B. weil weitere Dateien dort persistiert werden), dann:

  • Mount filebeat.yml nach z. B. /wazuh-config-mount/etc/filebeat.yml
  • Kopiere sie im Entrypoint/PostStart/InitContainer nach /etc/filebeat/filebeat.yml

Technisch ist das weniger elegant (Lifecycle-Hooks sind fehleranfälliger, Timing/Permissions können Probleme machen), aber es vermeidet den Overlay-Mount.

Archives aktivieren: filebeat.modules korrekt, sonst nichts „Kubernetes-spezifisches“

Dein filebeat.yml ist inhaltlich plausibel:

filebeat.modules:
  - module: wazuh
    alerts:
      enabled: true
    archives:
      enabled: true

Der Knackpunkt ist nicht „archives“, sondern wo und wie filebeat.yml gemountet wird.

Rules/Decoders sauber ergänzen ohne /var/ossec-Mount-Konflikte

Für zusätzliche Rules/Decoders gibt es zwei robuste Strategien:

  1. In das gleiche PV/SubPath-Layer integrieren, das ohnehin /var/ossec/etc bereitstellt (d. h. Dateien liegen bereits in der persistierten Struktur und werden nicht „von außen“ drüber gemountet).
  2. InitContainer, der ConfigMap-Inhalte nach /var/ossec/etc/{rules,decoders} kopiert (und damit keine Volume-Overlays erzeugt).

Was du vermeiden solltest:

  • Einzeldateien per subPath in Verzeichnisse zu mounten, die bereits aus einem anderen Volume stammen (/var/ossec/etc, /etc/filebeat).

Lessons Learned / Best Practices

  • Ein Verzeichnisbaum sollte immer aus genau einem Volume kommen. Kubernetes ist hier strikt – „mal eben eine Datei drüber mounten“ funktioniert nur, wenn das Zielverzeichnis nicht bereits aus einem anderen Volume stammt.
  • Wazuh-Fehler im Startup können sekundär sein. Wenn plötzlich ossec.conf „kaputt“ wirkt, zuerst Pod Events und Mount-Fehler prüfen.
  • Für Kubernetes-Deployments gilt:
    ConfigMap für Konfig + PV für Daten sauber trennen – und keine „Misch-Mounts“ in dieselben Pfade.
  • Für SOC/Forensik ist archives.json wertvoll, aber es sollte bewusst geplant werden: Index-Volumen, Retention, ILM/ISM und Storage-Kosten steigen.

Fazit

Das Aktivieren von Archives in Wazuh auf EKS scheitert in der Praxis häufig nicht an Filebeat oder Wazuh selbst, sondern an einem Kubernetes-Grundprinzip: Mount-Konflikte durch überlappende Volumes. Sobald /etc/filebeat bereits als Verzeichnis aus einem Volume kommt, darf filebeat.yml nicht als einzelne Datei aus einem anderen Volume darüber gemountet werden. Die saubere Lösung ist, /etc/filebeat vollständig aus einem einzigen ConfigMap-Volume zu mounten (oder alternativ per Copy-Mechanismus zu arbeiten). Das stabilisiert den Containerstart – und erst dann ist die Archives-Funktion zuverlässig nutzbar.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1769610726503359