Wazuh im Docker-Cluster horizontal skalieren: Warum der neue Worker keine Alerts liefert

von

Viele starten mit der offiziellen Wazuh Docker Multi-Node Deployment:
3× Indexer, 2× Manager, Dashboard, Nginx – alles auf einem Host.
Früher oder später kommt dann die Frage:

„Wie skaliere ich das Ganze horizontal auf einen zweiten Server und hänge dort einen weiteren Manager-Worker dran?“

Genau das hat der Nutzer im Thread versucht – mit einigen Stolpersteinen:

  • Docker-Multi-Node-Stack auf Device A
  • zusätzlicher Worker-Node auf Device B
  • Worker taucht im Cluster auf – aber: keine Alerts im Dashboard
  • außerdem merkwürdige indexer-connector-Warnings und Invalid ID-Meldungen im Log

Schauen wir uns an, was hier passiert ist – und was man daraus lernen kann.

1. Zwei Wazuh-Dokus – aber keine für Docker-Multi-Host

Der Nutzer hat zurecht gesehen, dass die Doku zwei Seiten anbietet:

  1. Wazuh server node(s) installation
    → Wie man einen neuen Serverknoten (Manager) installiert und als Worker konfiguriert.
  2. Configuring existing components to connect with the new node
    → Wie man bestehende Komponenten (Indexer, Dashboard, Load Balancer etc.) so anpasst, dass sie den neuen Node kennen.

Beide Anleitungen beziehen sich aber auf klassische Paketinstallationen (DEB/RPM) – nicht auf das Docker-Setup.
Im Docker-Stack hängen Konfigurationen, Zertifikate und URLs an:

  • docker-compose.yml
  • gemountete Config-Dateien unter ./config/…
  • Environment-Variablen (z. B. INDEXER_URL, WAZUH_MANAGER, Zert-Pfade)

Das macht „mal eben“ einen zweiten Host hinzufügen deutlich komplexer.

2. Setup des Users: Multi-Node auf Host A, Worker auf Host B

Host A:

  • Offizieller Multi-Node-Docker-Stack:
    • 3× Indexer
    • 2× Manager (master + worker)
    • Dashboard
    • Nginx-Proxy

Host B:

  • Ein einzelner zusätzlicher Manager-Worker im Docker-Container
  • erfolgreich in den Cluster eingebunden:
docker exec multi-node-wazuh.master-1 /var/ossec/bin/cluster_control -l

NAME      TYPE    VERSION  ADDRESS
manager   master  4.14.1   wazuh.master
worker01  worker  4.14.1   172.29.0.6
worker02  worker  4.14.1   172.17.20.133

Der neue Worker02 ist also clusterseitig sichtbar.

Außerdem sind auf Worker02 die üblichen Ports offen:

  • 1514–1516 (Agent-Verbindungen)
  • 55000 (Enrollment/Remote API)
  • 9200 (falls dort ebenfalls ein Indexer läuft – abhängig vom Setup)

Trotzdem: Keine Alerts im Dashboard.

3. Die entscheidenden Hinweise im Log

Auf dem neuen Worker laufen folgende Warnungen ins ossec.log:

indexer-connector: WARNING: IndexerConnector initialization failed for index 'wazuh-states-inventory-…-wazuh', retrying until the connection is successful.

wazuh-remoted: WARNING: (1408): Invalid ID 002 for the source ip: '172.17.20.124' (name 'unknown').
wazuh-remoted: WARNING: (1408): Invalid ID 001 for the source ip: '172.17.20.137' (name 'unknown').

Das verrät gleich mehrere Probleme:

3.1 IndexerConnector-Warnungen

„IndexerConnector initialization failed … retrying until the connection is successful.“

Der Worker versucht, sich mit dem Wazuh Indexer zu verbinden (für Inventar-Indizes wie wazuh-states-inventory-services-wazuh etc.), scheitert aber dauerhaft. Typische Ursachen:

  • falsche INDEXER_URL / INDEXER_PORT im Docker-Umfeld
  • falsche oder nicht passende TLS-Zertifikate (CA/Client-Zert)
  • Indexer nur auf Host A erreichbar, aber nicht aus dem Netz von Host B

Solange der Manager keinen stabilen Kontakt zum Indexer hat, wird er:

  • keine neuen Indizes (oder Templates) sauber initialisieren
  • und die Daten seiner Agents nicht in die Wazuh-Alerts-Indizes schreiben

→ Ergebnis: Worker02 sieht Agents, aber Dashboard sieht keine Daten von ihm.

3.2 Invalid ID-Meldungen

wazuh-remoted: WARNING: (1408): Invalid ID 002 for the source ip: '172.17.20.124' (name 'unknown').

Diese Meldung bedeutet:

  • Ein Agent mit ID 002 (bzw. 001) sendet Events an Worker02,
  • aber dieser Manager kennt diesen Agenten nicht in seiner client.keys / Agentdatenbank.

In einem Cluster werden die Agenten normalerweise vom Master verwaltet, aber:

  • alle Manager müssen die Agenteninfos konsistent haben
  • und die Agents sollten bevorzugt über Load Balancer / Nginx kommen, nicht direkt auf irgendeinen Worker, den sie nie registriert haben.

Solche Warnungen sind also ein Hinweis darauf, dass:

  • Agenten falsch geroutet sind (z. B. direkt auf Worker02 statt über den vorgesehenen Endpunkt)
  • oder die Replikation / Synchronisation der Agentendaten im Cluster noch nicht sauber läuft.

4. Der eigentliche Knackpunkt: Root-CA-Mount im Docker-Compose

Der User hat weiter geforscht und etwas Wichtiges entdeckt:

„I found that changing the mount in root-ca.pem for docker-compose.yml does not cause the WARNING to appear.
But the official default is ./config/wazuh_indexer_ssl_certs/root-ca-manager.pem. “

Heißt übersetzt:

  • Mit dem offiziellen Standardpfad zur root-ca-manager.pem schlagen die Indexer-Verbindungen (IndexerConnector) fehl.
  • Sobald er stattdessen eine andere root-ca.pem mountet (die zum Indexer-Cluster passt), verschwinden die Warnungen.

Das zeigt klar:

  • Der neue Worker auf Host B nutzte eine nicht passende CA
  • Seine TLS-Verbindung zum Indexer-Cluster (auf Host A) wurde abgelehnt
  • Erst mit der richtigen Root-CA des Indexer-Clusters konnte der Worker seine IndexerConnector-Verbindung sauber aufbauen

In einem Multi-Host-Szenario müssen alle:

  • Indexer
  • Manager (egal ob Docker oder Bare Metal)
  • Dashboard

die gleiche PKI-Basis kennen:

  • identische Root-CA
  • passende Zertifikate pro Komponente
  • korrekte Mounts in docker-compose.yml

Sobald hier gemischt wird (z. B. lokale Test-CA auf Host B, produktive CA auf Host A), funktioniert zwar der Cluster teilweise (Management-Kommunikation), aber IndexerConnector/TLS-Verbindungen scheitern – und damit bleibt der Worker praktisch „blind“ für das Dashboard.

5. Wie testet man, ob der Worker normal arbeitet?

Wenn du in einem ähnlichen Setup bist, kannst du so vorgehen:

  1. Cluster-Status prüfen
/var/ossec/bin/cluster_control -l
  • sehen alle Managerknoten gut aus?
  • gleiche Version? Master/Worker-Rollen korrekt?
  1. Indexer-Erreichbarkeit vom Worker testen

Im Worker-Container z. B.:

curl -k https://wazuh.indexer:9200

oder auf die im INDEXER_URL gesetzte Adresse.
Wenn hier schon TLS- oder Zertfehler kommen → CA/Zertifikat prüfen.

  1. TLS-Zertifikat-Pfade im Docker-Compose prüfen
  • stimmen die Pfade unter ./config/wazuh_indexer_ssl_certs/?
  • nutzt der Worker dieselbe Root-CA wie der Indexer-Cluster?
  1. Agenten gezielt auf Worker02 routen
  • testweise einen Agent über Nginx/Load Balancer so routen, dass er sicher bei Worker02 landet
  • im Worker-Log prüfen, ob:
    • keine Invalid ID-Warnings mehr kommen
    • und ob die Alerts aus diesem Agent in wazuh-alerts-* Indizes auftauchen

6. Fazit: Horizontal skalieren mit Docker – möglich, aber nichts „Out of the Box“

Was man aus diesem Fall mitnehmen kann:

  • Die offizielle Wazuh-Docker-Doku ist klar auf Ein-Host-Multi-Node ausgelegt.
  • Eine verteilte Docker-Cluster-Installation über mehrere Hosts ist möglich, aber:
    • deutlich fehleranfälliger
    • erfordert sehr saubere Arbeit mit:
      • Zertifikaten / Root-CA
      • Netzwerken / Ports
      • Umgebungsvariablen / URLs in docker-compose.yml
  • Warnungen wie:
    • IndexerConnector initialization failed …
    • (1408): Invalid ID …
      sind deine besten Freunde beim Debugging – sie zeigen dir klar:
    • „Kann den Indexer nicht erreichen“
    • „Agenten reden mit mir, die ich nicht kenne“

Der entscheidende Fix in diesem Thread war:

Das Mounten der richtigen Root-CA (root-ca.pem) für den Indexer-Cluster im Worker-Docker-Compose.

Erst damit konnte der Worker wirklich im Cluster „mitspielen“ und Daten ins gemeinsame Indexer-Backend schreiben.

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