Wazuh RBAC: Fehler bei benutzerdefinierten Dashboards und fehlenden Index-Rechten sauber beheben

Einleitung

Role-Based Access Control (RBAC) ist in Wazuh essenziell, um Mandantentrennung, Least-Privilege-Prinzip und organisatorische Zuständigkeiten sauber abzubilden. Besonders in Umgebungen mit mehreren Teams oder Kunden wird häufig ein separates Dashboard mit eingeschränkten Rechten benötigt – etwa für das Lesen und Verwalten bestimmter Agent-Gruppen.

In der Praxis treten dabei jedoch regelmäßig Fehler auf, die auf unvollständige Rollen-Zuweisungen oder eine fehlerhafte Dashboard-Konfiguration zurückzuführen sind. Dieser Artikel beleuchtet einen typischen Fall: Ein Benutzer erhält beim Zugriff auf das Dashboard eine Fehlermeldung bezüglich fehlender Berechtigungen auf Indizes – obwohl die Schritte aus der offiziellen RBAC-Dokumentation befolgt wurden.


Ausgangslage / Problemstellung

Ein Administrator erstellt gemäß Wazuh-Dokumentation einen internen Benutzer mit eingeschränkten Rechten, konkret gemäß Use Case:

„Give a user permissions to read and manage a group of agents“

Dabei werden:

  • eine benutzerdefinierte Rolle,
  • entsprechende Policies,
  • sowie Role-Mappings für den internen Benutzer

konfiguriert.

Trotzdem erscheint beim Login im Wazuh Dashboard eine Fehlermeldung, die darauf hinweist, dass keine ausreichenden Berechtigungen zum Lesen der Index-Daten bestehen.

Die Konfiguration enthält bereits:

run_as: true

in der Datei:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Dennoch bleibt das Problem bestehen.


Technische Analyse

Die Ursache solcher Fehler liegt typischerweise in einem der folgenden Punkte:

1. RBAC wirkt nur mit aktiviertem run_as

Das Wazuh Dashboard nutzt für die Kommunikation mit der Wazuh API standardmäßig den technischen Benutzer wazuh-wui. Damit Benutzerrollen korrekt greifen, muss:

run_as: true

gesetzt sein.

Ist run_as deaktiviert, werden die Benutzerrechte nicht korrekt angewendet – selbst wenn die Rolle technisch korrekt definiert wurde.

Die RBAC-Dokumentation beschreibt diesen Mechanismus explizit.
Quelle:
https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html


2. Unterschied zwischen „Read-only“, „Internal User“ und „Custom Role“

Die Dokumentation unterscheidet mehrere Szenarien:

  • Read-only Benutzer
  • Interne Benutzer
  • Benutzer mit benutzerdefinierten Rollen
  • Admin-Benutzer

Ein häufiger Fehler besteht darin, einen Benutzer nur mit minimalen Leserechten auszustatten, jedoch:

  • keine Index- oder Alert-Permissions korrekt zuzuweisen
  • oder keine passenden Resource-Filter zu definieren

Gerade beim Use Case „Read and manage a group of agents“ müssen neben Agentenrechten auch entsprechende Rechte auf die zugehörigen Indizes (z. B. wazuh-alerts-*) vorhanden sein. Fehlt diese Verknüpfung, entsteht der Eindruck eines „Index-Permission-Fehlers“.


3. Inkonsistente oder unvollständige Role-Mappings

RBAC in Wazuh basiert auf:

  • Policies
  • Roles
  • Role Mappings
  • Internal Users

Wird einer dieser Schritte ausgelassen oder falsch referenziert (z. B. falscher Rollenname im Mapping), greift die Policy nicht – obwohl sie technisch existiert.

In der Praxis passiert häufig:

  • Policy korrekt erstellt
  • Rolle korrekt erstellt
  • Mapping verweist jedoch auf falsche Rolle
  • oder Benutzer wurde vor der finalen Konfiguration erstellt und nicht neu zugeordnet

Die Folge: Rechte greifen nicht wie erwartet.


4. Cache- und Session-Probleme im Dashboard

Nach Änderungen an RBAC-Konfigurationen sollten immer:

sudo systemctl restart wazuh-dashboard

durchgeführt werden.

Zusätzlich:

  • Browser-Cache leeren
  • Cookies löschen
  • ggf. in privatem Fenster testen

Alte Sessions können sonst weiterhin mit veralteten Token-Claims arbeiten.


Lösung / Best Practices

Der nachhaltigste Lösungsweg besteht darin, die RBAC-Konfiguration vollständig neu und strikt nach Dokumentation aufzubauen – ohne alte Artefakte weiterzuverwenden.

Offizielle Anleitung:
https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html#use-case-give-a-user-permissions-to-read-and-manage-a-group-of-agents

Empfohlene Vorgehensweise:

Schritt 1 – Bestehende Konfiguration entfernen

  • Testbenutzer löschen
  • Custom Roles löschen
  • Role Mappings löschen
  • Policies löschen

So wird verhindert, dass alte Konfigurationen weiterwirken.


Schritt 2 – Use Case exakt nach Dokumentation neu umsetzen

In dieser Reihenfolge:

  1. Policy erstellen
  2. Rolle erstellen (mit Referenz auf Policy)
  3. Role Mapping erstellen
  4. Internen Benutzer erstellen
  5. Benutzer der Rolle zuordnen

Wichtig:

  • Rollennamen exakt übernehmen
  • Resource-Filter korrekt setzen
  • Index- und Agent-Permissions nicht vermischen

Schritt 3 – run_as: true verifizieren

Datei prüfen:

/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml

Konfiguration:

run_as: true

Dashboard neu starten.


Schritt 4 – Dashboard-Service neu starten

sudo systemctl restart wazuh-dashboard

Danach:

  • Browser-Cache leeren
  • Neu anmelden

Lessons Learned / Best Practices

1. RBAC ist strikt hierarchisch aufgebaut.
Fehlt nur eine Verknüpfung, greifen die Rechte nicht.

2. run_as ist kein optionaler Parameter.
Ohne aktiviertes run_as funktionieren benutzerbezogene Rollen nicht wie erwartet.

3. Änderungen immer mit Neustart validieren.
RBAC-Claims werden in Tokens verarbeitet – alte Sessions können veraltete Berechtigungen enthalten.

4. Konfiguration lieber neu aufsetzen als patchen.
Gerade bei RBAC spart ein sauberes Redesign oft mehr Zeit als Fehlersuche in bestehenden Artefakten.

5. Index-Rechte nicht vergessen.
Agent-Rechte allein reichen nicht – Alerts und Events liegen in Indizes (wazuh-alerts-*), die ebenfalls gelesen werden müssen.


Fazit

RBAC in Wazuh funktioniert zuverlässig, wenn die Konfiguration konsistent und vollständig umgesetzt wird. Die häufigsten Fehler entstehen durch unvollständige Role-Mappings, fehlende Index-Permissions oder ein nicht aktiviertes run_as.

Die sauberste Lösung bei unerklärlichen Berechtigungsfehlern ist meist: Konfiguration entfernen und strikt nach Dokumentation neu implementieren. In den meisten Fällen führt dieser Ansatz unmittelbar zum Erfolg.


Quellenverweis

https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html
https://documentation.wazuh.com/current/user-manual/user-administration/rbac.html#use-case-give-a-user-permissions-to-read-and-manage-a-group-of-agents

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