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

von

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)
  2. 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