Archive Indexing in Wazuh 4.14.1 auf Kubernetes (EKS): Warum Environment-Variablen nicht greifen und wie man Archive sauber und supportkonform indexiert

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Die Indexierung von Wazuh Archives (archives.json) ist ein häufiges Thema in SIEM-Umgebungen, wenn nicht nur Alerts, sondern alle Events (inklusive nicht alertender Logs) durchsuchbar sein sollen. In klassischen Bare-Metal- oder VM-Installationen ist das Aktivieren von Archive Indexing vergleichsweise trivial. In Kubernetes-Deployments, insbesondere auf AWS EKS, greifen diese Mechanismen jedoch nicht immer wie erwartet. Dieser Beitrag erklärt, warum Environment-Variablen wie FILEBEAT_ARCHIVES_ENABLED nicht ausreichen, weshalb Pod-Änderungen zu Instabilitäten führen können und welcher unterstützte Weg für Wazuh 4.14.1 auf Kubernetes empfohlen ist.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Umgebung:

  • Wazuh Manager 4.14.1
  • Deployment auf Kubernetes (AWS EKS)
  • Standard Kubernetes-Deployment/Helm-basierter Ansatz

Beobachtete Probleme:

  • Setzen von FILEBEAT_ARCHIVES_ENABLED=true als Environment-Variable:
    • Variable ist im Pod vorhanden
    • /etc/filebeat/filebeat.yml bleibt unverändert (archives.enabled: false)
  • Bereitstellung einer eigenen filebeat.yml über ConfigMap:
    • Manager-Pod (Master) startet instabil oder crasht intermittierend
  • Direkte Änderungen im Pod sind nicht persistent und gehen bei jedem Restart verloren

Ziel:

  • Wazuh Archives (archives.json) sollen indexiert und im Dashboard durchsuchbar sein
  • Lösung soll persistierend, supportkonform und Kubernetes-tauglich sein

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1. Archive Indexing besteht aus zwei voneinander abhängigen Schritten

Archive Indexing funktioniert in Wazuh nur, wenn beide Ebenen korrekt konfiguriert sind:

  1. Manager-Ebene (ossec.conf)
    Der Wazuh Manager muss angewiesen werden, alle Events in JSON-Form zu schreiben:
    • logall_json erzeugt /var/ossec/logs/archives/archives.json
  2. Indexer/Shipper-Ebene (Filebeat)
    Filebeat muss diese Archive-Datei lesen und an den Indexer senden

Fehlt eine der beiden Ebenen, erscheinen keine Archive-Daten im Indexer.

Offizielle Dokumentation:

2. Warum FILEBEAT_ARCHIVES_ENABLED in Kubernetes nicht greift

In Kubernetes-Deployments wird die filebeat.yml nicht dynamisch aus Environment-Variablen generiert. Stattdessen:

  • Die Filebeat-Konfiguration ist statisch im Container-Image oder wird
  • über Helm-Templates / ConfigMaps beim Pod-Start eingebunden

Das bedeutet:

  • Eine Environment-Variable allein ändert die effektive filebeat.yml nicht
  • Das Verhalten unterscheidet sich bewusst von VM-/Package-Installationen

Das erklärt, warum die Variable im Pod sichtbar ist, die Konfiguration aber unverändert bleibt.

3. Warum eine unvollständige ConfigMap zu Pod-Crashes führen kann

Wenn eine eigene filebeat.yml per ConfigMap gemountet wird, treten häufig diese Fehler auf:

  • Teile der originalen Wazuh-Filebeat-Konfiguration fehlen
  • Module, Pipelines oder Pfade werden überschrieben
  • Filebeat startet, findet aber erwartete Wazuh-spezifische Blöcke nicht

Ergebnis:

  • Filebeat-Prozess beendet sich
  • Abhängige Container/Sidecars verursachen Pod-Restarts

Wichtig: Filebeat-Konfigurationen dürfen nicht „minimal“ ersetzt werden, sondern müssen die Wazuh-Defaults vollständig berücksichtigen.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Archive-Erzeugung im Manager aktivieren (Cluster-weit)

In Kubernetes erfolgt dies über die Cluster-Konfiguration (master.conf / worker.conf), nicht über einzelne Pods.

<ossec_config>
  <global>
    <jsonout_output>yes</jsonout_output>
    <alerts_log>yes</alerts_log>
    <logall>yes</logall>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Diese Konfiguration ist der zwingende erste Schritt.
Ohne logall_json existiert keine indexierbare Archive-Datei.

Dokumentation:
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html

Schritt 2: Filebeat-Archive-Modul in Kubernetes korrekt aktivieren

Unterstützter Weg in Kubernetes:

  • Nutzung des offiziellen Wazuh Kubernetes Deployments / Helm Charts
  • Anpassung der values.yml, um:
    • das Archive-Modul zu aktivieren
    • oder eine vollständige, valide Filebeat-Konfiguration bereitzustellen

Dabei gilt:

  • Keine „Inline-Edits“ im laufenden Pod
  • Keine isolierten Overrides einzelner Parameter ohne Kontext

Referenz:
https://documentation.wazuh.com/current/deployment-options/deploying-with-kubernetes/kubernetes-deployment.html

Schritt 3: Custom Filebeat-Konfiguration nur vollständig und bewusst einsetzen

Falls eine eigene filebeat.yml nötig ist:

  • Ausgangspunkt immer die originale Wazuh-Filebeat-Konfiguration
  • Nur gezielt archives.enabled: true setzen
  • Alle Module, Pipelines und Pfade beibehalten

Index-Namen für Archives:

  • Standard: wazuh-archives-4.x-*

Dokumentation:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer/wazuh-indexer-indices.html

Schritt 4: Auswirkungen bedenken (Storage & Performance)

Archive Indexing bedeutet:

  • Deutlich mehr Daten im Indexer
  • Höherer Storage- und I/O-Bedarf
  • Längere Retention erfordert Index Lifecycle Management (ILM/ISM)

Empfehlung:

  • Archive Indexing nur aktivieren, wenn es fachlich erforderlich ist
  • Retention-Policy definieren

Dokumentation:
https://documentation.wazuh.com/current/user-manual/wazuh-indexer-cluster/index-lifecycle-management.html

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Environment-Variablen ersetzen keine Filebeat-Konfiguration in Kubernetes
  • Archive Indexing ist ein zweistufiger Prozess (Manager + Filebeat)
  • Pod-interne Änderungen sind immer ephemer
  • Filebeat-Overrides müssen vollständig kompatibel mit Wazuh sein
  • Archive Indexing erhöht Last – Retention und Sizing sind Pflicht

Fazit (knappe Zusammenfassung mit Mehrwert)

In Wazuh 4.14.1 auf Kubernetes lässt sich Archive Indexing nicht zuverlässig über Environment-Variablen aktivieren. Der supportkonforme Weg besteht darin, zuerst die Archive-Erzeugung im Manager (logall_json) zu aktivieren und anschließend Filebeat über Helm/ConfigMap sauber und vollständig für Archive Indexing zu konfigurieren. Direkte Pod-Änderungen oder unvollständige Filebeat-Overrides führen unweigerlich zu Instabilität. Mit einer korrekten Kubernetes-Integration und klarer Retention-Strategie wird Archive Indexing jedoch auch auf EKS stabil und skalierbar 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/p1768489508207749