Check both Wazuh permission mappings for a read-only user

Bottom line: Do not close a read-only account request after creating the identity. Review the two documented permission mappings and test the intended account’s actual reading and administrative boundaries.

Source fact: documented behavior

The Wazuh RBAC – How to create and map internal users guide configures indexer read permissions and a read-only tenant for the internal read-only user.

It separately maps that internal user to the Wazuh readonly role through the server’s role-mapping workflow.

The procedure requires run_as to be true, then calls for a dashboard restart and clearing the browser cache and cookies.

What the source does not establish

This article follows the documented internal read-only account procedure. It does not approve access to every index or tenant, design a custom document restriction or claim that successful authentication proves the requested authorization boundaries.

Applicability questions

• Which internal identity is being reviewed?
• What indexer role and tenant permissions are actually mapped?
• What separate Wazuh server role mapping applies?
• Which permitted reads and prohibited changes must be demonstrated?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a two-layer permission review followed by positive and negative tests using the actual intended read-only identity.

1. Write the account’s intended reading tasks before copying a role example. Identify the information population and tenant it is allowed to reach. Treat the source’s broad example permissions as a procedure to assess, not automatic approval for every organization. Have the data owner identify any narrower requirements that need a separate role design and review.
2. Inspect the indexer mapping and the Wazuh server role mapping as two distinct entries in the account record. Confirm that both refer to the same intended internal identity. Review the documented runtime setting and refresh actions with the dashboard operator, preserving a recovery administrator and a maintenance allowance for the restart rather than experimenting with the only available management session.
3. Start the validation with a fresh browser session for the intended user after the planned refresh. Attempt the approved reading tasks and the specifically prohibited administrative action. Keep the administrator’s successful session out of the acceptance evidence. If one layer works and another does not, investigate that mapping directly instead of granting a broader role merely to suppress the error.

Verification and evidence

Proposed verification: prepare an allowed view, an excluded information population if the approved design includes one, and a harmless administrative action that the read-only identity must not perform. Record the expected outcome for each before signing in. Use a test account or approved isolated arrangement; no account creation or permission change was performed for this article.

Retain the redacted identity reference, both role mappings, the reviewed runtime setting and actual observations from the fresh user session. An incomplete negative test remains an open authorization question. Do not report the account as accepted merely because the dashboard loads, a role label says read-only or an administrator can retrieve the same data.

Official references

• Wazuh RBAC – How to create and map internal users — Wazuh; official product documentation.

Source review completed October 30, 2026. Recheck the official source and deployment-specific applicability before changing production settings.