Alerting/reports/vizualisations with RBAC (single-tenant) + permissions issue with alerts/monitors for users
Uni AT
Dear Wazuh team,
Our deployment consists of 3 Wazuh Server docker containers (v4.14.7) with an OpenSearch integration for logs indexing.
All our users belong to specific RBAC groups. Document-level Security (DLS) is also used used on wazuh-archives-* and wazuh-alerts-* indexes to make sure that the user from a RBAC group only see the alerts/archives of the agent(s) in his group. We are not using multi-tenancy.
The goal is to make sure that the users from each RBAC group can create his own alerts/monitors (Alerting section), his own reports (Reporting section), his own visualisations (Visualize section) and his own dashboards (Dashboards section).
Ideally, we would like everything to be separated: users from a group shouldn't see what users from other group(s) created.
1) We understand that there are some limitations with single-tenancy for the dashboards: all custom dashboards are stored in the same shared .kibana index, and what we understand is that there is no way to prevent them from viewing other group's dashboards. Do you confirm this is really the case, is that it will remain the same with Wazuh 5 and single-tenancy? That the only option would be to have multitenancy enabled?
2) For reports/alerts&monitors/visualisations, do you confirm that it is the same as with dashboards? Can you confirm in which .kibana/opendistro index each of those objects are stored?
3) We encounter multiple permission issues when trying to authorize the users to read/modify the alerts and monitors in the Alerting section. In particular, one blocking point is the impossibility to choose an index (wazuh-alerts-*, wazuh-archives-*) in the dropdown list.
Here is the configuration example we have for a specific RBAC group (1.png):
The opendistro_ZID_users group is a custom group with the following permissions (2.png):
More information about each of those permissions: https://docs.opensearch.org/latest/security/access-control/permissions/
Now the error we are facing (red rectangle below - 3.png) with a user from this RBAC group. We analyzed the requests using the browser developer tools, and it turns out that some index-level permissions were supposedly missing. We tried to add those in the RBAC role section (screenshot 1) for wazuh-alerts-* and wazuh-archives-*, but it still didn't work (dropdown list empty) and we ended up getting new permission errors in the requests. In the below screenshot is one of the several permission errors we get while typing an index in the empty dropdown list or clicking on it:
Can you please tell exactly which cluster permissions and index permissions are required for non-admin users to view/modify the alerts/monitors in the Alerts section? We tried multiple permission combinations both on the cluster and index levels, but none of them could fix this dropdown list issue.
If you can also provide a similar list of permissions required for the dashboards, reports and visualiations, it would be very helpful.
I am aware that we are asking for a lot of information. We would be happy to provide you with any other information you might need to answer more accurately; hopefully this will help the community too.
Thank you very much in advance for all the help you can bring for those inquiries.
Have a nice day,
Olamilekan Abdullateef Ajani
Thank you for the detailed description and screenshots, helps isolate the issue.
- For Dashboards and visualizations
With multi-tenancy disabled, dashboards, visualizations, saved searches, and index patterns are saved in the shared .kibana index. DLS on wazuh-alerts-* and wazuh-archives-* controls the documents users can query, but it does not isolate these saved objects by RBAC group.
Your screenshot also shows the global tenant as read-only. This prevents users from saving dashboards and visualizations. Making it read/write would allow saving, but the objects would then be shared with every user who has access to that tenant.
The documentation reveals the recommended solution is to enable multi-tenancy, create one custom tenant per RBAC group, and grant each group read/write access only to its own tenant. The global tenant can remain read-only or be hidden.
Ref:
https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/multi-tenancy.html
Alerting monitors are not Dashboard saved objects and are not separated by Dashboard tenants. OpenSearch documentation states that monitors run with the permissions—including DLS—of the user who created or last modified them.
Ref: https://documentation.wazuh.com/current/user-manual/wazuh-dashboard/multi-tenancy.html
Reporting is slightly different from Alerting: report definitions and instances contain a tenant value and are filtered by tenant. The Reporting plugin can additionally use plugins.alerting.filter_by_backend_roles.
- Empty index dropdown
The error in the screenshot, no permissions for [indices:admin/aliases/get], is not a missing document-read permission on wazuh-alerts-*.
The Alerting index picker performs index and alias discovery and retrieves mappings. These are index-metadata operations. In Wazuh 4.14.7, the built-in alerting_full_access role grants exactly the following:
cluster_permissions:
- cluster_monitor
- 'cluster:admin/opendistro/alerting/*'
- 'cluster:admin/opensearch/alerting/*'
- 'cluster:admin/opensearch/notifications/feature/publish'
index_permissions:
- index_patterns:
- '*'
allowed_actions:
- indices_monitor
- 'indices:admin/aliases/get'
- 'indices:admin/mappings/get'
Ref: https://github.com/wazuh/wazuh-indexer/blob/v4.14.7/distribution/src/config/security/roles.yml#L48-L61
The metadata permissions must apply to * because the picker performs cluster-wide index and alias discovery. Granting them only on wazuh-alerts-* and wazuh-archives-* is insufficient.
These permissions expose index names, aliases, mappings, and monitoring information. They do not grant document retrieval and therefore do not replace or bypass the DLS rules protecting the Wazuh documents.
The recommended configuration is:
Keep a custom data role containing only the explicit Wazuh index patterns and their DLS queries.
Also map the group to the built-in alerting_full_access role.
Map it to reports_full_access if users must create and manage reports.
Map it to notifications_full_access if users must create or modify notification channels. Use notifications_read_access only when users merely need to select existing channels.
Using the built-in roles is preferable to maintaining a custom list of plugin actions because the built-in definitions are updated with the installed version.
Also removing these entries from the current custom role:
The direct .opendistro-alerting-config / system:admin/system_index permission. Alerting should access its system index through the plugin APIs.
The * > read permission. It grants document-level read access to unrelated indices that are not covered by the Wazuh DLS entries. Replace it with explicit index patterns.
Separating monitors and channels between groups
Enable backend-role filtering:
PUT /_cluster/settings
{
"persistent": {
"plugins.alerting.filter_by_backend_roles": true,
"opensearch.notifications.general.filter_by_backend_roles": true
}
}
Each RBAC group must have a unique backend role. Users from different groups must not share a backend role used for this filtering.
This is important because, when a regular user creates a monitor without explicitly specifying rbac_roles, OpenSearch associates all of that user’s backend roles with the monitor. Role such as all_users would therefore make monitors visible across groups. The same concern applies to any other backend role shared by all users.
Please also check whether the users are mapped to the kibana_read_only security role. The default configuration includes that role in opensearch_security.readonly_mode.roles, which prevents creation through the Dashboard UI.
You can verify the effective backend roles, security roles, and tenants with:
curl -k -u zid_test "https://<indexer>:9200/_plugins/_security/authinfo?pretty"
Then test the metadata requests as the same user:
curl -k -u zid_test "https://<indexer>:9200/_cat/indices/wazuh-alerts*?format=json"
curl -k -u zid_test "https://<indexer>:9200/_cat/aliases/wazuh-alerts*?format=json"
curl -k -u zid_test "https://<indexer>:9200/wazuh-alerts-*/_mapping"
After the dropdown works, create and execute a monitor as a group user and confirm that the results contain only agents permitted by that user’s DLS query.
An alternative is config.dynamic.do_not_fail_on_forbidden: true, which can omit unauthorized indices instead of failing the complete request. However, this changes Security plugin behavior cluster-wide, so I recommend treating it as a secondary option and testing it before using it in production.