Wazuh Index-Patterns in Discover verbergen oder umbenennen: Was geht nicht – und welche Multi-Tenancy-Workarounds funktionieren

von

Einleitung

Sobald Wazuh produktiv genutzt wird, taucht ein wiederkehrendes Bedürfnis auf: Nicht jeder Nutzer soll in OpenSearch Dashboards (Wazuh Dashboard) im Discover-Dropdown alle Index-Patterns sehen – vor allem nicht technische Wazuh-States- oder Vulnerability-Indizes wie wazuh-states-vulnerabilities-*. Gleichzeitig sollen die Nutzer aber weiterhin die Wazuh-Apps (z. B. Vulnerability/IT Hygiene/Endpoints) bedienen können. Genau an dieser Stelle kollidieren Erwartungen mit den technischen Grenzen von OpenSearch Dashboards und der Art, wie Wazuh bestimmte Indizes/Patterns verwendet.

Ausgangslage / Problemstellung

In der Umgebung existieren mehrere Wazuh-Index-Patterns (u. a. wazuh-alerts-*, wazuh-states-*, wazuh-states-vulnerabilities-*). Ein eingeschränkter Benutzer soll:

  • im Discover möglichst nur „seine“ fachlichen Index-Patterns sehen (z. B. Alerts eines Mandanten/Standorts),
  • nicht durch technische Patterns verwirrt werden,
  • aber weiterhin Vulnerability-/IT-Hygiene-Ansichten in den Wazuh-Plugins nutzen können.

Zusätzlicher Kontext aus dem Thread: Bei einem eingeschränkten Nutzer fehlen auf der Endpoints-Seite (Agent Summary / Top OS / Top Groups) Werte – was typischerweise auf fehlende API-/RBAC-Rechte im Wazuh-Manager-Kontext hindeutet.

Technische Analyse

1) Umbenennen von Wazuh-Systemindizes: praktisch nicht vorgesehen

Wazuh nutzt definierte Index-Namenskonventionen und -Patterns, die in mehreren Komponenten (Indexer-Templates, Dashboard-Objekte, Plugins, teils auch Quellcodepfade) erwartet werden. In der Wazuh-Dokumentation ist explizit dokumentiert, welche Index-Patterns Wazuh standardmäßig verwendet (z. B. wazuh-alerts-* und verschiedene wazuh-states-*).

Das bedeutet in der Praxis: Ein „harmloses“ Umbenennen einzelner Indizes/Patterns führt sehr schnell zu Seiteneffekten (fehlende Visualisierungen, kaputte Plugin-Queries, leere Dashboards), weil Dashboards/Plugins weiterhin auf die Original-Patterns zeigen.

2) „Nur im Discover verstecken“ ist in OpenSearch Dashboards nicht als RBAC-Funktion gelöst

Die zentrale Einschränkung kommt aus OpenSearch Dashboards selbst: In einem Tenant, in dem ein Nutzer berechtigt ist, werden die Index Patterns in der Discover-Auswahl grundsätzlich angezeigt – unabhängig davon, ob der Nutzer auf die zugrundeliegenden Indizes Zugriff hat. Genau diese Lücke ist seit Jahren bekannt und wurde als Feature Request diskutiert.

Damit ist „verstecken nur im Discover“ nicht sauber über Index-Level-Permissions lösbar. Ergebnis: Man kann Nutzer effektiv daran hindern, Daten zu lesen – aber nicht verhindern, dass sie das Pattern im Dropdown sehen (was dann zu Fehlermeldungen/Verwirrung führt).

3) Der realistische Hebel ist Mandanten-/Tenant-Trennung (Multi-Tenancy)

OpenSearch Dashboards löst Sichtbarkeit von Saved Objects (inkl. Index Patterns, Visualisierungen, Dashboards) über Tenants. Multi-Tenancy ist dafür das vorgesehene Konzept: global/private/custom Tenants, jeweils mit Rollen-Zuordnung und Read/Write-Rechten.

Wazuh dokumentiert zudem die Aktivierung/Verwendung von Multi-Tenancy im Wazuh Dashboard (OpenSearch Dashboards) und die relevanten opensearch_security.multitenancy.*-Einstellungen.

Lösung / Best Practices

Zielkonflikt sauber auflösen: „Discover sauber halten“ vs. „Wazuh-Plugins vollständig nutzbar“

Es gibt zwei praxistaugliche Betriebsmodelle – je nachdem, was wichtiger ist:

Modell A: Discover „sauber“ halten über einen restriktiven Tenant (empfohlen, wenn Discover für Endnutzer wichtig ist)

Prinzip: Nutzer arbeiten in einem Custom Tenant, in dem nur die gewünschten Index Patterns existieren. Technische Wazuh-Patterns werden in diesem Tenant gar nicht erst angelegt – dann können sie im Discover-Dropdown auch nicht auftauchen.

  1. Multi-Tenancy aktivieren (Wazuh Dashboard / OpenSearch Dashboards)
    Wazuh beschreibt die Aktivierung inkl. opensearch_security.multitenancy.enabled und preferred tenant order.
    OpenSearch dokumentiert die Multi-Tenancy-Mechanik und Konfigurationsoptionen.
  2. Custom Tenant anlegen, z. B. tenant_ops_readonly
  3. Admin-Workflow für Saved Objects definieren
  • Ein Admin (oder Service-User) bekommt Write auf diesen Tenant
  • Der Admin legt im Tenant die Index Patterns an, die Endnutzer sehen sollen (z. B. wazuh-alerts-tenantA-*)
  • Endnutzer bekommen Read-only auf den Tenant
  1. Rollen sauber trennen
  • Index-Permissions: nur auf die fachlich erlaubten Indizes
  • Tenant-Permissions: read auf den Custom Tenant
  • Optional: Discover komplett sperren (Feature Controls) – wenn Discover nicht benötigt wird (siehe Modell B)

Wichtiges Caveat (Wazuh-spezifisch):
Wenn Nutzer ausschließlich in einem restriktiven Tenant arbeiten, können Wazuh-Plugins leere Bereiche zeigen, falls dort erwartete Index Patterns (für Wazuh-States/Vulnerabilities) nicht existieren. Dann muss ein Admin die benötigten Patterns/Saved Objects gezielt im Tenant bereitstellen – oder die Nutzer wechseln für Wazuh-Plugin-Arbeit in einen Tenant, der die Wazuh-Standardobjekte enthält. (Das ist genau der operative Trade-off bei Tenant-Isolation.)

Modell B: Discover für eingeschränkte Nutzer deaktivieren, Wazuh-Plugins normal nutzbar lassen (empfohlen, wenn Discover nicht benötigt wird)

Wenn das eigentliche Problem „Verwirrung im Discover“ ist, aber Discover fachlich gar nicht gebraucht wird, ist die robusteste Maßnahme: Discover entziehen statt Patterns verstecken zu wollen.

OpenSearch Dashboards kennt Feature-/App-Permissions (Dashboards-Funktionen sind über Security/Permissions steuerbar; fehlende Rechte blenden/versperren Bereiche).
Damit bleibt:

  • Wazuh-Plugin-Nutzung möglich (je nach Role/Permissions),
  • Discover ist weg,
  • Index-Pattern-Dropdown ist kein Thema mehr.

Dieses Modell ist in SOC-Setups häufig sinnvoll, wenn Endnutzer ausschließlich über kuratierte Dashboards/Apps arbeiten sollen und nicht „frei suchen“.

Ergänzung: Warum „Index-Permissions auf wazuh-states-vulnerabilities-* geben“ das eigentliche Ziel verfehlt

Das Berechtigen von wazuh-states-vulnerabilities-* löst zwar Zugriffsfehler – aber es versteckt nichts. Das Pattern bleibt sichtbar, weil Sichtbarkeit an Tenant-/Saved-Object-Ebene hängt, nicht an Index-Rechten. Das ist genau der Kern des OpenSearch-Themas.

Lessons Learned / Best Practices

  • Index Patterns sind Saved Objects: Sichtbarkeit ist Tenant-getrieben, nicht Index-permission-getrieben. Wer „Dropdown-Sichtbarkeit“ steuern will, braucht Tenants.
  • Wazuh-Standard-Index-Patterns nicht umbenennen: Wazuh setzt auf definierte Patterns; Abweichungen verursachen Folgeschäden in Dashboards/Plugins. Als Referenz: Wazuh dokumentiert die Standardpatterns und deren Zweck.
  • Saubere Rollenarchitektur:
    • „Data roles“ (Index-level: was darf gelesen werden?)
    • „UI roles“ (Dashboards features: Discover ja/nein)
    • „Tenant roles“ (wo dürfen Saved Objects existieren?)
  • Operationalisieren: Wenn ein restriktiver Tenant genutzt wird, braucht es einen Admin-Prozess zum Anlegen/Updaten der benötigten Index Patterns und Dashboards im richtigen Tenant, sonst „wirkt“ Wazuh für die Nutzer kaputt.

Fazit

Einzelne Wazuh-Indizes wie wazuh-states-vulnerabilities-* lassen sich in der Praxis weder risikolos umbenennen noch „nur im Discover verstecken“, weil OpenSearch Dashboards die Index-Pattern-Liste tenantweit zeigt. Der belastbare Weg ist entweder (a) ein dedizierter Tenant mit kuratierten Index Patterns oder (b) Discover für die Zielgruppe konsequent deaktivieren und ausschließlich kuratierte Wazuh-Ansichten/Dashboards bereitzustellen. Damit wird aus einer UI-Verwirrung eine kontrollierte, wartbare Berechtigungs- und Mandantenstrategie.

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