Wazuh Cloud mit GKE: Warum DaemonSet-Agents „keine Daten“ liefern, gcp-pubsub mit Exit Code 1 läuft und wie man Agent-Pods, Inventar und Auto-Cleanup richtig betreibt

von

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

In GKE-Umgebungen entstehen zwei Datenpfade, die in Wazuh sauber zusammenspielen müssen: Cluster-/Workload- und Node-nahe Telemetrie (über Wazuh Agents im Cluster) sowie Cloud-Service-Logs (z. B. VPC Flow Logs, DNS, Firewall) – häufig über Pub/Sub. Wenn Agents zwar enrollen, im Dashboard aber fast nur „Agent started / disconnected“ erscheint, ist das meist kein „Cloud-Problem“, sondern ein Kombinationseffekt aus (a) DaemonSet Scheduling, (b) unvollständiger Agent-Konfiguration (logcollector/syscheck) und (c) fehlenden Dependencies für gcp-pubsub auf Agent-Seite.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

  • Wazuh Cloud wird evaluiert, GKE-Integration erfolgt über Wazuh Agents als DaemonSet (nach offizieller Doku).
  • Agents registrieren erfolgreich, aber im Dashboard erscheint kaum Telemetrie.
  • Container-Logs zeigen u. a.:
    • wazuh-logcollector: INFO: (1905): No file configured to monitor.
    • wazuh-syscheckd: ... File integrity monitoring disabled.
    • wazuh-modulesd:gcp-pubsub ... WARNING: Command returned exit code 1
  • Pub/Sub-Modul ruft wodles/gcloud/gcloud ... auf, scheitert in der Shell-Ausführung.
  • Cluster hat 33 Nodes, aber nur 6 Agent-Pods laufen (für ein DaemonSet untypisch).

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

1) „Keine Daten“ im Agent-Dashboard: logcollector/syscheck sind faktisch nicht konfiguriert

Die gezeigten Logs sind sehr eindeutig:

  • Logcollector startet, hat aber keine <localfile>-Definitionen → er sammelt nichts. Der Logcollector überwacht nur Dateien/Commands, die explizit konfiguriert wurden.
  • Syscheck/FIM ist deaktiviert („No directory provided … File integrity monitoring disabled“) – also auch kein File Inventory / FIM.

In der bereitgestellten ossec.conf wird praktisch nur <client> + <enrollment> + <gcp-pubsub> geschrieben. Das erklärt, warum fast nur Agent-Lifecycle-Events sichtbar sind.

2) gcp-pubsub Exit Code 1: Agent-seitige Dependencies fehlen (das ist dokumentiert)

Wazuh erlaubt die GCP-Module entweder auf Manager oder Agent zu konfigurieren – entscheidend ist, wo Sie Zugriff auf GCP und Credentials/Identity abbilden. Wichtig dabei: Dependencies müssen nur installiert werden, wenn Sie die Integration auf einem Agent ausführen. Der Manager enthält sie bereits.

Wenn im Agent-Container ein ModuleNotFoundError (z. B. pytz) auftaucht, passt das exakt zu „Agent-Deployment ohne Dependency-Setup“.

Zusätzlich: Die <gcp-pubsub>-Sektion hat definierte Optionen und Einschränkungen; insbesondere wird in der Doku darauf hingewiesen, dass nur eine gcp-pubsub-Sektion pro Konfigurationsdatei unterstützt wird (weitere Services → mehrere Agents).

3) Nur 6 Pods bei 33 Nodes: Das ist sehr wahrscheinlich Scheduling (Taints/Tolerations, NodeSelector, Ressourcen, Autopilot)

Ein DaemonSet erzeugt grundsätzlich 1 Pod pro (eligible) Node. Wenn nur 6 Pods laufen, ist fast immer einer dieser Gründe aktiv:

  • Nodes sind tainted (z. B. NoSchedule) und das DaemonSet hat keine passende tolerations
  • NodePools/Nodes sind durch nodeSelector / affinity ausgeschlossen
  • Ressourcenanforderungen sind zu hoch / Pod wird nicht schedulbar
  • In GKE Autopilot gelten zusätzliche Einschränkungen (Privileged, hostPath, etc.), wodurch Pods evtl. gar nicht auf allen Nodes laufen dürfen

Dieser Effekt korreliert direkt mit „keine Daten“: Wenn nur ein Teil der Nodes Agents hat, fehlen Node-Logs/Runtime-Logs und Inventory entsprechend.

4) „Auto-deregister“ bei dynamischen Nodes: Nicht automatisch, aber steuerbar über Disconnection-Time + API-Cleanup

Wazuh entfernt Agents nicht automatisch beim Disconnect. Es gibt jedoch zwei praxistaugliche Hebel:

  • agents_disconnection_time steuert, wann ein Agent als „disconnected“ gilt.
  • Über die Wazuh Server API können Agents entfernt werden, die „disconnected“ oder „never connected“ sind – parametrisiert über status und older_than.

Wazuh beschreibt zudem das „Purging non-active agents“ als Betriebs-Pattern.

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

A) Agent sammelt nichts: Minimal-Telemetrie sauber aktivieren

  1. Logquellen definieren (Beispiel: Node-Logs / Container-Runtime-Logs – je nach Runtime/Path):
  • Wazuh erklärt die korrekte Konfiguration von <localfile> und Log-Monitoring-Strategien.
  1. FIM/Syscheck gezielt konfigurieren (wenn Node-Dateisysteme/Verzeichnisse überwacht werden sollen):
  • In Kubernetes braucht es dafür i. d. R. zusätzliche hostPath-Mounts (z. B. / oder /etc, /var/lib, /var/log) und eine klare Entscheidung, was wirklich überwacht werden darf/soll.

Wichtig: Privileged + hostPath ist in vielen Umgebungen (z. B. Autopilot) eingeschränkt; das muss zum Cluster-Modus passen.

B) gcp-pubsub auf Agent-Seite: Entweder Dependencies installieren oder Integration serverseitig betreiben

  • Wenn Sie Pub/Sub im Agent ausführen wollen, folgen Sie der offiziellen Prerequisite-/Dependency-Doku – dort steht explizit, dass die Dependencies für Agent-Setups separat installiert werden müssen.
  • Konfiguration der <gcp-pubsub>-Sektion: Syntax und Optionen sind dokumentiert.

Best Practice für Cloud-/Managed-Umgebungen:
Wenn Sie keine Agent-Images härten/erweitern wollen, ist eine serverseitige GCP-Integration oft operativ stabiler (weil der Manager die Dependencies „out of the box“ hat).

Sicherheitsaspekt „Static Keys“:
Workload Identity ist aus Kundensicht häufig das Ziel. Wenn das jeweilige Wodle/Script zwingend eine credentials_file erwartet, ist das ein echtes Architekturthema. Dann bleibt aktuell oft nur:

  • Keys kurzlebig managen/rotieren
  • oder Integration anders platzieren (z. B. zentral, mit dedizierter IAM-Rolle, streng begrenzt)

C) DaemonSet läuft nur auf wenigen Nodes: Kubernetes-Debug-Playbook

  • kubectl get ds wazuh-agent -o wide
  • kubectl describe ds wazuh-agent → Events: „FailedScheduling“, Taints, Affinity
  • kubectl get nodes -o json | jq '.items[].spec.taints' (Taints)
  • Prüfen, ob tolerations, nodeSelector, affinity gesetzt werden müssen

Solange nicht alle gewünschten NodePools abgedeckt sind, bleibt die Agent-Telemetrie fragmentiert.

D) Agent-Cleanup in dynamischen Clustern: praktikabler Kompromiss

  1. agents_disconnection_time passend setzen, damit „tote“ Nodes schneller als disconnected gelten.
  2. Cleanup über API endpoint (z. B. regelmäßig per Job) mit status=disconnected und older_than=…. Das ist der offizielle Mechanismus zum Entfernen inaktiver Agents.

Für Kubernetes-spezifische Betriebsstabilität (persistente Identitäten/Keys) lohnt sich außerdem ein Blick auf Wazuhs Deployment-Strategien für Agents in Kubernetes (z. B. Persistenz via PV/Stateful Patterns), um „Agent-Flapping“ und Agent-Leichen zu reduzieren.

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

  • Enrollment ≠ Telemetrie. Wenn logcollector „No file configured“ meldet, wird im Dashboard zwangsläufig wenig erscheinen.
  • GCP-Module auf Agent-Seite sind dependency-sensitiv. Offiziell: Dependencies sind bei Agent-Integrationen zu installieren, Manager bringt sie mit.
  • DaemonSet Coverage ist ein Muss. Wenn nur ein Bruchteil der Nodes läuft, ist die Observability zwangsläufig unvollständig.
  • Auto-Removal ist (noch) nicht nativ. Disconnection-Time + API-Cleanup ist der dokumentierte Weg.
  • Eine gcp-pubsub Sektion pro Agent-Konfig beachten; bei mehreren Subscriptions/Services sauber planen (mehrere Agents/Deployments).

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn Wazuh Agents in GKE zwar registrieren, aber „keine Daten“ liefern, ist die Ursache fast immer in der Agent-Konfiguration (fehlende <localfile>-/FIM-Settings) und/oder im Kubernetes-Scheduling (DaemonSet läuft nicht auf allen Nodes) zu finden. Beim Pub/Sub-Wodle ist entscheidend: Auf Agent-Seite müssen die GCP-Dependencies installiert werden; serverseitig sind sie bereits enthalten. Operativ lässt sich Agent-Wildwuchs in dynamischen Clustern mit agents_disconnection_time und API-basiertem Cleanup gut kontrollieren, auch wenn echtes Auto-Deregistration aktuell nicht „out of the box“ passiert.

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/p1768424390161369