Passwortänderungen in Wazuh auf Kubernetes: Fallstricke, Reihenfolge und Best Practices

Aus maxTechCorner

Einleitung

Der Betrieb von Wazuh auf Kubernetes bringt viele Vorteile in Bezug auf Skalierbarkeit und Automatisierung – erhöht aber gleichzeitig die Komplexität bei sicherheitsrelevanten Änderungen. Besonders deutlich wird dies beim Ändern von Benutzerpasswörtern für Indexer- und API-Komponenten. Ein scheinbar einfacher Vorgang kann schnell zu Authentifizierungsfehlern oder nicht mehr erreichbaren Services führen, wenn die Abhängigkeiten zwischen Secrets, Pods und internen Wazuh-Komponenten nicht korrekt berücksichtigt werden.

Dieser Beitrag analysiert einen Community-Fall, in dem Passwortänderungen in einer lokalen Kubernetes-Deployment-Variante nicht wie erwartet funktionierten, obwohl die offizielle Dokumentation befolgt wurde.

Ausgangslage / Problemstellung

Die Umgebung basierte auf einer lokalen Kubernetes-Installation von Wazuh gemäß offizieller Anleitung: https://documentation.wazuh.com/current/deployment-options/deploying-with-kubernetes/kubernetes-deployment.html

Der Administrator versuchte, sowohl Indexer-Benutzer (admin, kibanaserver) als auch Wazuh Server API Benutzer zu aktualisieren. Dabei traten folgende Unsicherheiten und Probleme auf:

  • Passwortänderung schlug fehl, obwohl alle Schritte dokumentationskonform ausgeführt wurden
  • Mehrere Benutzer wurden gleichzeitig geändert
  • Unklarheit über:

notwendige Rollouts vs. Pod-Löschung

  • Unterschiede zwischen Indexer- und API-Benutzern
  • Abweichungen zwischen Docker- und Kubernetes-Dokumentation

Keine offensichtlichen Fehler in den Logs

Die relevanten Dokumentationsseiten:

Technische Analyse

Unterschiedliche Benutzerklassen, unterschiedliche Mechanismen

In Wazuh auf Kubernetes existieren zwei klar getrennte Authentifizierungsbereiche:

  1. Wazuh Indexer Benutzer
  • Definiert in internal_users.yml
  • Abgebildet in Kubernetes Secrets (z. B. indexer-cred-secret.yaml)
  • Müssen aktiv in den Indexer geladen werden (securityadmin.sh)
  1. Wazuh Server API Benutzer
  • Definiert ausschließlich über Kubernetes Secrets
  • Keine Indexer-Abhängigkeit
  • Kein securityadmin.sh erforderlich

Diese Trennung ist funktional korrekt, wird in der Praxis jedoch häufig vermischt – insbesondere, wenn mehrere Passwörter gleichzeitig geändert werden.

Zentrales Problem: Gleichzeitige Passwortänderung

Das gleichzeitige Ändern mehrerer Benutzer (z. B. admin und kibanaserver) kann zu inkonsistenten Zuständen führen:

  • Ein Pod startet bereits mit neuen Secrets
  • Ein anderer verwendet noch alte Credentials
  • Ergebnis: Authentifizierungsfehler ohne klare Log-Hinweise

Gerade in Kubernetes, wo Pods asynchron neu gestartet werden, ist dies ein klassischer Race Condition-Effekt.

Session-Cookies als zusätzliche Fehlerquelle

Ein oft übersehener Punkt: aktive Dashboard-Sessions.

Wenn man vor der Passwortänderung nicht aus dem Wazuh Dashboard ausgeloggt ist, bleiben alte Session-Cookies bestehen. Nach der Passwortänderung äußert sich das häufig als:

  • Login-Seite nicht erreichbar
  • „Unauthorized“-Fehler trotz korrekter Zugangsdaten

Siehe dazu auch: https://documentation.wazuh.com/current/deployment-options/docker/changing-default-password.html#logging-out-of-your-wazuh-dashboard

Rollout vs. Pod-Deletion

Die Dokumentation verwendet stellenweise explizite Pod-Namen und kubectl delete pod …. Diese sind nur Beispiele.

Technisch entscheidend ist:

  • Pods müssen neu starten, damit sie Secrets neu einlesen
  • kubectl rollout restart ist funktional gleichwertig und deutlich sauberer

Für lokale Kubernetes-Deployments gilt zudem: 

kubectl apply -k envs/local-env/

Dies entspricht dem in der Dokumentation erwähnten „Apply the manifest changes“, auch wenn dort primär EKS genannt wird.

Lösung / Best Practices

Empfohlene Reihenfolge für Passwortänderungen

1. Abmelden vom Wazuh Dashboard Vor jeder Änderung zwingend erforderlich.

2. Benutzer einzeln ändern – niemals parallel

  • Erst admin, vollständig testen
  • Danach kibanaserver
  • Danach ggf. API-Benutzer

3. Indexer-Benutzer

  • internal_users.yml anpassen
  • Kubernetes Secret aktualisieren
  • Manifeste anwenden
  • securityadmin.sh ausführen
  • Dashboard- und Manager-Pods neu starten

4. API-Benutzer

  • wazuh-api-cred-secret.yaml ändern
  • Manifeste anwenden
  • Manager- und Dashboard-Pods neu starten
  • Kein securityadmin.sh

Passwortanforderungen beachten

API-Benutzer:

  • 8–64 Zeichen
  • Groß- und Kleinbuchstaben
  • Zahl
  • Sonderzeichen

Indexer-Benutzer:

  • Keine $ oder & verwenden (Probleme mit Kubernetes Secrets)
  • Keine benutzerdefinierten User vergessen – sonst werden sie entfernt

Lessons Learned / Best Practices

  • Passwortänderungen in Kubernetes sind kein atomarer Vorgang
  • Dokumentation beschreibt Schritte korrekt, aber nicht immer die Hintergründe
  • Gleichzeitige Änderungen mehrerer Benutzer vermeiden
  • Rollout-Restarts sind sauberer als Pod-Deletion
  • Logs können trotz Fehlern unauffällig bleiben – Reihenfolge ist entscheidend
  • Docker- und Kubernetes-Deployments sind nicht 1:1 vergleichbar

Fazit

Passwortänderungen in Wazuh auf Kubernetes scheitern selten an einzelnen Befehlen, sondern fast immer an Reihenfolge, Parallelität und fehlender Trennung der Benutzerklassen. Wer Indexer- und API-Benutzer sauber auseinanderhält, Änderungen sequenziell durchführt und Pods gezielt neu startet, vermeidet unnötige Ausfälle und schwer nachvollziehbare Authentifizierungsprobleme.

Der analysierte Community-Fall zeigt, dass selbst korrekt befolgte Dokumentation ohne architektonisches Verständnis zu Frustration führen kann – und warum Best Practices im Kubernetes-Betrieb entscheidend sind.

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

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 9. Januar 2026).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Passwortänderungen_in_Wazuh_auf_Kubernetes:_Fallstricke,_Reihenfolge_und_Best_Practices&oldid=2971“