If you’re deploying Wazuh for multiple teams, business units, managed customers, or departments, giving every user access to the same dashboards and security data quickly becomes difficult to manage. Security analysts only need visibility into the environments they are responsible for, while administrators must ensure that sensitive logs, alerts, and saved dashboards remain isolated from other users. This is where Wazuh multi-tenancy becomes valuable.

Wazuh multi-tenancy allows multiple groups of users to share a single Wazuh infrastructure while keeping their dashboards, visualizations, searches, and access permissions logically separated.

Rather than deploying a completely independent Wazuh stack for every customer or department, organizations can centrally manage data collection while controlling exactly what each user can see.

Properly configured multi-tenancy offers several advantages:

• Improves security by enforcing least-privilege access
• Simplifies administration for large organizations
• Reduces infrastructure costs compared to multiple deployments
• Makes Managed Security Service Provider (MSSP) environments easier to manage
• Enables scalable growth without duplicating infrastructure

In this guide, you’ll learn how Wazuh multi-tenancy works, how it integrates with the OpenSearch Security plugin, how to configure tenants, users, roles, and permissions, and the best practices for securely separating multiple organizations within a single Wazuh deployment.

What Is Wazuh Multi-Tenancy?

Definition of Multi-Tenancy in Wazuh

Multi-tenancy is the ability for multiple independent groups of users (called tenants) to share the same Wazuh deployment while keeping their dashboards, saved objects, and access permissions isolated from one another.

A tenant does not create a completely separate Wazuh installation.

Instead, it provides logical separation inside the existing deployment.

Each tenant can have its own:

• Dashboards
• Saved searches
• Visualizations
• Index patterns
• Reports
• Alert views
• User permissions

The underlying Wazuh Manager and Wazuh Indexer continue collecting and processing security events for the entire environment while access to that data is controlled through the OpenSearch Security plugin.

How Tenant Isolation Works

Tenant isolation occurs primarily at the Wazuh Dashboard and OpenSearch Security layers.

When users authenticate:

1. They are assigned one or more backend roles.
2. Backend roles map to OpenSearch roles.
3. Roles determine which tenants the user may access.
4. Roles also determine which indexes can be queried.
5. Dashboards only display objects stored within the active tenant.

For example:

• Customer A cannot see Customer B’s dashboards.
• Finance cannot access Engineering dashboards.
• SOC analysts only view alerts for permitted indexes.
• Administrators may access every tenant.

This separation greatly reduces the risk of accidental information disclosure while allowing a centralized deployment.

Benefits of Separating Users and Organizations

Organizations often adopt multi-tenancy because it balances centralized management with strong access controls.

Major benefits include:

• Reduced infrastructure costs by sharing one Wazuh cluster
• Easier administration compared to managing multiple deployments
• Strong access control using role-based permissions
• Better compliance with least-privilege security principles
• Simplified onboarding of new customers or departments
• Easier dashboard customization for different audiences
• Centralized upgrades and maintenance

For Managed Security Service Providers (MSSPs), multi-tenancy enables hundreds of customers to be managed from a single deployment while maintaining logical separation between each client.

The principle of least privilege is widely recommended by organizations such as National Institute of Standards and Technology as a foundational security control.

Common Use Cases

Multi-tenancy is useful in many production environments.

Typical deployments include:

Managed Security Service Providers (MSSPs)

Each customer receives:

• Separate dashboards
• Dedicated users
• Individual visualizations
• Customer-specific reporting

without requiring a separate Wazuh installation.

Large Enterprises

Different business units often require independent visibility.

Examples include:

• Finance
• Human Resources
• Engineering
• Operations
• Retail stores
• Regional offices

Each department maintains its own dashboards while sharing the same infrastructure.

Government Organizations

Government agencies frequently separate data by:

• Department
• Clearance level
• Region
• Project

Role-based access ensures users only access authorized information.

Educational Institutions

Universities often manage:

• Student labs
• Research departments
• Administrative systems
• Campus infrastructure

Each team can customize dashboards without affecting others.

Multi-Tenancy vs Multiple Wazuh Deployments

Many administrators wonder whether they should use multi-tenancy or simply deploy multiple Wazuh environments.

Multi-tenancy is usually the preferred option when organizations trust a shared infrastructure and only require logical separation.

Multiple Wazuh deployments may be preferable when organizations require:

• Complete infrastructure isolation
• Independent software versions
• Different compliance boundaries
• Separate network environments
• Air-gapped deployments

If you’re designing a highly available environment before enabling multi-tenancy, see The Complete Wazuh Cluster Architecture Guide.

How Wazuh Multi-Tenancy Works

Although users often think of multi-tenancy as a dashboard feature, it actually involves several components working together:

• Wazuh Dashboard
• OpenSearch Security
• Wazuh Indexer
• Wazuh Manager

Each plays a different role in isolating users while sharing the same infrastructure.

Wazuh Dashboard

The Wazuh Dashboard provides the user interface where tenants become visible.

Each tenant maintains its own collection of saved objects that are invisible to users working in other tenants unless explicitly granted access.

Dashboards

Every tenant can create independent dashboards tailored to its own environment.

Examples include:

• Windows security monitoring
• Linux servers
• Cloud infrastructure
• Kubernetes
• PCI compliance
• Threat hunting

Changes made inside one tenant do not affect dashboards stored in another tenant.

Saved Searches

Saved searches are also tenant-specific.

A SOC team may save searches for:

• Failed logins
• Malware detections
• Critical alerts
• Authentication failures

while another department maintains completely different searches.

Visualizations

Charts, graphs, heat maps, pie charts, and timelines are stored independently within each tenant.

This enables different teams to build dashboards suited to their operational needs without interfering with one another.

Tenant-Specific Objects

In addition to dashboards and visualizations, tenants store:

• Index patterns
• Saved queries
• Reports
• Canvas objects
• Discover configurations

This logical separation is one of the primary benefits of multi-tenancy.

OpenSearch Security

The OpenSearch Security plugin provides the authorization layer that makes multi-tenancy possible.

Rather than Wazuh itself deciding who can access data, OpenSearch Security authenticates users and enforces permissions based on configured roles.

Roles

Roles define permissions such as:

• Index access
• Cluster permissions
• Tenant permissions
• Dashboard privileges

A role might allow:

• Read-only access to alerts
• Full dashboard administration
• Index management
• Tenant administration

Role Mappings

Role mappings connect authenticated users to security roles.

Mappings may be based on:

• Individual usernames
• LDAP groups
• Active Directory groups
• Backend roles
• SAML attributes
• OIDC claims

This allows organizations to integrate existing identity providers with Wazuh.

If you’re using directory-based authentication, see How to Configure Wazuh LDAP Authentication.

Users

Users authenticate through OpenSearch Security.

Each user can belong to multiple roles, allowing flexible permission assignments across different tenants.

Backend Roles

Backend roles are often supplied by:

• LDAP
• Active Directory
• SAML
• OpenID Connect

These external identity systems simplify permission management because administrators manage group membership centrally rather than assigning permissions individually.

Wazuh Indexer

The Wazuh Indexer stores all collected alerts and events.

Although data resides within shared indexes, access is enforced through security policies.

Index Permissions

Roles specify:

• Which indexes users may query
• Whether users have read or write access
• Administrative permissions
• Snapshot permissions

For example:

A customer role may only access:

wazuh-alerts-*

while administrators can access every security index.

If you’re planning your storage architecture, see The Ultimate Wazuh Indexer Guide and How to Configure Wazuh Index State Management (ISM).

Security Plugin

The OpenSearch Security plugin intercepts every request before it reaches the indexes.

It validates:

• User identity
• Assigned roles
• Tenant permissions
• Index permissions
• Cluster permissions

Unauthorized requests are rejected before any data is returned.

Data Access Control

Data access combines:

• Authentication
• Authorization
• Role mappings
• Index permissions
• Tenant permissions

Together, these controls ensure users only retrieve information they are authorized to view, even though multiple tenants share the same Wazuh deployment.

Wazuh Manager

Unlike dashboards and indexes, the Wazuh Manager itself is not tenant-aware.

Instead, it serves as the centralized engine responsible for collecting, analyzing, and generating security events for all connected agents.

Shared Manager Architecture

All agents communicate with the same Wazuh Manager (or cluster of managers).

The manager performs:

• Log collection
• File Integrity Monitoring
• Vulnerability detection
• Syscheck
• Rootcheck
• Active Response
• Rule evaluation

regardless of tenant ownership.

Agent Data Collection

Agents continue forwarding events normally.

The manager does not distinguish whether an endpoint belongs to Customer A or Customer B during collection.

Tenant isolation occurs later through permissions applied within the indexer and dashboard.

Rule Processing

Detection rules execute globally across all incoming events.

Custom rules, decoders, and integrations continue functioning exactly as they would in a single-tenant deployment.

For more on custom detections, see The Complete Custom Wazuh Rules and Decoders Guide.

Alert Generation

After rules execute, alerts are indexed into the Wazuh Indexer.

From that point onward, OpenSearch Security determines which users are permitted to query and visualize those alerts based on their assigned roles and tenant permissions.

Prerequisites

Before configuring Wazuh multi-tenancy, verify that your environment meets the following requirements.

Supported Wazuh Versions

Multi-tenancy is supported in modern Wazuh releases that use the Wazuh Dashboard with OpenSearch Security.

Ensure all core components,Manager, Indexer, and Dashboard, are running compatible versions, and avoid mixed-version deployments during upgrades to prevent authorization inconsistencies.

Required User Privileges

Initial configuration requires administrative privileges because you’ll be creating tenants, assigning roles, and modifying security settings.

Typically, you’ll need permission to:

• Create and edit tenants
• Create users and roles
• Configure role mappings
• Manage index permissions
• Restart services if configuration changes require it

Wazuh Dashboard

A functioning Wazuh Dashboard installation is required because tenant management and saved objects are administered through the dashboard interface.

Verify that:

• Users can successfully log in
• Dashboard plugins load correctly
• Security features are enabled
• Dashboard can communicate with the Wazuh Indexer

If you’re experiencing dashboard issues, see Wazuh Dashboard Not Loading? Complete Troubleshooting Guide.

Wazuh Indexer

Your Wazuh Indexer must be healthy before configuring multi-tenancy.

Check for:

• Green cluster health
• Working authentication
• Healthy indexes
• Proper communication with the Dashboard

Address any cluster health issues first, for example, How to Fix a Yellow Cluster Status in Wazuh Indexer or How to Fix Wazuh All Shards Failed Error.

OpenSearch Security Enabled

Multi-tenancy depends on the OpenSearch Security plugin.

If the security plugin is disabled, tenant isolation, role mappings, and index-level authorization are unavailable.

Confirm that:

• Security is enabled on the Indexer
• Authentication is functioning
• Roles and role mappings can be managed
• Tenant support is enabled in the Dashboard configuration where applicable

Review the OpenSearch Security documentation for deployment-specific configuration guidance.

Planning Your Multi-Tenant Architecture

Before creating users and roles, spend time designing your multi-tenant architecture.

A well-planned permission model is much easier to maintain than trying to reorganize tenants after hundreds of users and dashboards have already been created.

The goal is to answer three questions:

• Who should access the environment?
• What data should they see?
• What actions should they be allowed to perform?

A clear design reduces administrative overhead, minimizes security risks, and makes onboarding new teams much faster.

Identify Tenant Boundaries

The first step is determining what each tenant represents.

There is no universal approach. Your tenant structure should reflect how your organization operates and how you want to isolate security data.

Departments

Many organizations create a tenant for each department.

For example:

• Finance
• Human Resources
• Engineering
• IT Operations
• Sales
• Customer Support

Each department receives:

• Its own dashboards
• Saved searches
• Visualizations
• Reports

This allows every team to customize its workspace without affecting others.

This approach works well when departments manage separate infrastructure or have different reporting requirements.

Customers

For Managed Security Service Providers (MSSPs), a common design is one tenant per customer.

Example:

Customer-A
Customer-B
Customer-C
Customer-D

Each customer receives:

• Dedicated dashboards
• Isolated visualizations
• Separate reports
• Restricted access to their own alert data

Administrators can still manage every customer from the same Wazuh deployment while customers remain isolated from one another.

This model significantly reduces infrastructure costs compared to deploying a separate Wazuh environment for every client.

Business Units

Large enterprises often organize security around business units rather than departments.

Examples include:

• Retail
• Manufacturing
• Logistics
• Healthcare
• Corporate Services

Each business unit may operate independently with its own security team while sharing centralized Wazuh infrastructure.

Geographic Regions

Global organizations frequently separate tenants by region.

Example:

North America
Europe
Asia-Pacific
South America

Regional tenants simplify:

• Compliance requirements
• Local reporting
• Regional SOC operations
• Data ownership

Keep in mind that tenant separation alone does not provide data residency guarantees.

If regulations require data to remain within a specific country or jurisdiction, separate Wazuh deployments may still be necessary.

Design User Roles

Once tenants are defined, determine what different users should be allowed to do.

Avoid assigning permissions directly to users whenever possible. Instead, assign users to roles and manage permissions centrally.

This approach follows Role-Based Access Control (RBAC), which scales much better as your environment grows.

Administrators

Administrators typically require broad access across the deployment.

Common permissions include:

• Manage users
• Create tenants
• Modify roles
• Manage indexes
• Configure dashboards
• View all alerts
• Perform maintenance

Because administrator accounts have extensive privileges, access should be limited to trusted personnel and protected with strong authentication.

Security Analysts

Security analysts usually require access to investigate incidents but not administer the platform.

Typical permissions include:

• View alerts
• Search indexes
• Build dashboards
• Save visualizations
• Run threat hunting queries
• Generate reports

Analysts generally do not need permission to:

• Delete indexes
• Create users
• Modify security settings
• Change cluster configuration

Read-Only Users

Read-only users are ideal for management teams or stakeholders who only need visibility into security data.

Permissions generally include:

• View dashboards
• Search alerts
• Read reports
• Export results

These users should not be able to:

• Edit dashboards
• Save objects
• Create visualizations
• Modify tenant content

Auditors

Compliance and audit teams often require temporary or restricted access.

Typical capabilities include:

• Review security events
• View compliance dashboards
• Export evidence
• Verify monitoring coverage

Restricting auditors to read-only permissions helps preserve the integrity of dashboards and saved objects during compliance reviews.

Define Index Access

Tenant isolation alone does not prevent users from querying unauthorized data.

Access to the underlying indexes must also be carefully planned using OpenSearch Security roles.

Shared Indexes

Most Wazuh deployments store alerts in shared indexes such as:

wazuh-alerts-*

Access to these indexes is controlled through role permissions rather than physical separation.

Advantages include:

• Simpler administration
• Lower storage overhead
• Easier upgrades
• Shared cluster resources

This is the most common architecture for organizations using logical isolation.

Dedicated Indexes

Some organizations create dedicated indexes for specific customers or business units.

Examples:

customer-a-alerts-*
customer-b-alerts-*
finance-alerts-*
engineering-alerts-*

Benefits include:

• Stronger logical separation
• Easier retention management
• Customer-specific lifecycle policies
• Simpler regulatory reporting

However, maintaining many separate indexes increases operational complexity and requires careful shard planning.

If you’re designing large-scale storage, see How to Design a Wazuh OpenSearch Shard Allocation Strategy and How to Manage Wazuh Storage.

Least Privilege Model

Always follow the principle of least privilege.

Rather than granting broad access, give users only the permissions necessary to perform their responsibilities.

For example:

According to the Cybersecurity and Infrastructure Security Agency, implementing least-privilege access is a fundamental practice for reducing the impact of compromised accounts and limiting lateral movement within enterprise environments.

Create Users

After planning your architecture, the next step is creating the accounts that will access your Wazuh environment.

User management is handled by the OpenSearch Security plugin.

Depending on your environment, users can either be created internally or authenticated through an external identity provider such as LDAP, Active Directory, SAML, or OpenID Connect.

Creating Internal Users

Internal users are stored within the OpenSearch Security configuration.

They are commonly used for:

• Small deployments
• Testing environments
• Administrative accounts
• Emergency access accounts

For production environments with many users, integrating with an enterprise identity provider is generally easier to maintain.

If your organization uses directory services, see How to Configure Wazuh LDAP Authentication.

Password Policies

Strong password policies help protect privileged accounts from unauthorized access.

Recommended practices include:

• Minimum password length of 14–16 characters
• Complex passphrases instead of short passwords
• Unique passwords for every account
• Regular credential rotation for privileged users
• Multi-factor authentication where supported
• Immediate removal of unused accounts

Avoid sharing administrator credentials among multiple users.

Each administrator should have an individual account for auditing purposes.

Service Accounts

Service accounts are intended for applications rather than interactive users.

Examples include:

• Automation scripts
• API integrations
• Monitoring systems
• CI/CD pipelines
• Scheduled reporting

Service accounts should:

• Have narrowly scoped permissions
• Use long, randomly generated credentials
• Be rotated regularly
• Be monitored for unusual activity

Never reuse administrator accounts for automated tasks.

Authentication Methods

OpenSearch Security supports multiple authentication methods.

Common options include:

• Internal user database
• LDAP
• Active Directory
• SAML
• OpenID Connect (OIDC)
• Proxy-based authentication

The best choice depends on your organization’s identity management strategy.

Enterprise deployments generally benefit from centralized authentication because user lifecycle management remains synchronized with existing identity providers.

Example Commands

The following example demonstrates creating an internal user with the OpenSearch Security administration tools.

Exact commands may vary depending on your Wazuh and OpenSearch versions.

curl -k -u admin:admin \
-X PUT "https://localhost:9200/_plugins/_security/api/internalusers/soc_analyst" \
-H "Content-Type: application/json" \
-d '{
  "password": "ReplaceWithAStrongPassword",
  "backend_roles": [
    "soc_analysts"
  ]
}'

You can verify that the user exists by retrieving the configured internal users:

curl -k -u admin:admin \
https://localhost:9200/_plugins/_security/api/internalusers

Note: Replace default credentials before deploying to production, and avoid embedding passwords directly in automation scripts. Use a secure secrets manager whenever possible.

Create Roles

Roles define what authenticated users are allowed to do after logging in.

Rather than assigning permissions directly to each user, create reusable roles that can be mapped to multiple users or backend groups.

This approach simplifies administration and keeps permissions consistent across the environment.

A typical role combines:

• Cluster permissions
• Index permissions
• Tenant permissions
• Dashboard permissions

Cluster Permissions

Cluster permissions control administrative operations affecting the entire OpenSearch cluster.

Examples include:

• Monitoring cluster health
• Viewing node information
• Managing snapshots
• Managing templates
• Viewing cluster statistics

Only trusted administrators should receive broad cluster permissions.

Security analysts generally require little or no cluster-level access.

Index Permissions

Index permissions determine which indexes a role can access and what actions may be performed.

Typical privileges include:

• Read documents
• Search indexes
• Create indexes
• Write documents
• Delete documents
• Manage index settings

Restrict index access to only the alert indexes users need.

For example:

wazuh-alerts-*

rather than granting unrestricted access to every index in the cluster.

Dashboard Permissions

Dashboard permissions control what users can do within the Wazuh Dashboard.

Examples include:

• View dashboards
• Create dashboards
• Save visualizations
• Edit searches
• Manage reports
• Access tenant settings

Many organizations create separate roles such as:

• Dashboard Administrator
• Security Analyst
• Read-Only Viewer
• Executive Dashboard Viewer

This keeps permissions easier to understand and audit.

Least Privilege Examples

A practical role design might look like this:

Keeping roles narrowly scoped reduces the chance of accidental changes while simplifying future audits.

Example Role Configuration

The following example illustrates a role that grants read access to Wazuh alert indexes and permission to work within a specific tenant:

{
  "cluster_permissions": [
    "cluster_composite_ops_ro"
  ],
  "index_permissions": [
    {
      "index_patterns": [
        "wazuh-alerts-*"
      ],
      "allowed_actions": [
        "read"
      ]
    }
  ],
  "tenant_permissions": [
    {
      "tenant_patterns": [
        "Customer-A"
      ],
      "allowed_actions": [
        "kibana_all_read"
      ]
    }
  ]
}

This role is suitable for analysts who need to investigate alerts within a single tenant but should not administer the cluster or modify other tenants’ resources.

Configure Role Mappings

After creating users and roles, the next step is to connect them together through role mappings.

Role mappings determine which permissions a user receives after authentication.

Without a role mapping, a user may be able to log in successfully but will not have permission to access dashboards, indexes, or tenants.

A role mapping can associate a role with:

• Individual users
• Backend roles
• LDAP groups
• Active Directory groups
• SAML attributes
• OpenID Connect (OIDC) claims

This approach makes permission management significantly easier, especially in large enterprise environments.

Map Users to Roles

The simplest configuration maps individual users directly to a role.

Example:

This approach works well for:

• Small organizations
• Test environments
• Proof-of-concept deployments

However, it becomes difficult to manage as the number of users increases.

For production environments, mapping backend roles is usually the better approach.

Backend Roles

Backend roles allow permissions to be inherited from an external authentication provider.

For example:

Active Directory Group
        │
        ▼
Backend Role
        │
        ▼
OpenSearch Role
        │
        ▼
Tenant Permissions

Instead of assigning permissions to hundreds of individual users, administrators simply place users into the appropriate directory group.

Benefits include:

• Centralized user management
• Faster onboarding
• Easier employee offboarding
• Consistent permission assignments
• Reduced administrative overhead

External Identity Providers

OpenSearch Security supports several external identity providers.

Common integrations include:

• LDAP
• Microsoft Active Directory
• SAML
• OpenID Connect (OIDC)
• Proxy authentication

When a user logs in:

1. The identity provider authenticates the user.
2. Backend roles are returned.
3. OpenSearch maps those backend roles to security roles.
4. Security roles determine index and tenant access.
5. The Wazuh Dashboard displays only authorized resources.

For enterprise deployments, this approach is far more scalable than maintaining an internal user database.

If you’re integrating directory services, see How to Configure Wazuh LDAP Authentication.

Verification Steps

After configuring role mappings, verify that they function as expected.

Recommended validation steps include:

• Log in using a test account.
• Confirm the correct tenant is visible.
• Verify unauthorized tenants do not appear.
• Open the Discover page and confirm only authorized indexes are searchable.
• Ensure dashboards load correctly.
• Attempt an unauthorized action and verify access is denied.
• Review OpenSearch Security logs for authentication or authorization errors.

Testing with multiple user accounts before deploying to production helps prevent permission issues that could expose sensitive data or block legitimate users.

Example Configuration

The following example maps the backend role soc_analysts to a security role.

soc_analyst_role:
  backend_roles:
    - "soc_analysts"

  users:
    - "alice"

  hosts: []

  and_backend_roles: []

In this example:

• Any user belonging to the soc_analysts backend role automatically receives the permissions associated with soc_analyst_role.
• The user alice also receives the role directly.

For large environments, backend role mappings are generally preferred because they reduce ongoing administrative effort.

Create and Configure Tenants

Once roles have been configured, you can create the tenants that users will access.

A tenant acts as an isolated workspace within the Wazuh Dashboard.

It stores dashboards, visualizations, saved searches, reports, and other dashboard objects independently from other tenants.

Users can only access tenants that have been explicitly assigned to their security roles.

Create Private Tenants

Every user automatically has access to a Private Tenant.

A private tenant is intended for personal work and experimentation.

Typical uses include:

• Testing dashboards
• Building new visualizations
• Creating temporary searches
• Personal investigations

Objects stored in a private tenant are invisible to other users.

Private tenants are useful for development but are generally not recommended for collaborative SOC workflows.

Create Global Tenants

A Global Tenant is shared among authorized users.

Organizations often use a global tenant for:

• Company-wide dashboards
• Executive reporting
• SOC overview dashboards
• Shared visualizations
• Standardized reports

Changes made within the Global Tenant are immediately visible to other users with access.

Because multiple administrators may modify shared dashboards, change management procedures are recommended to avoid accidental overwrites.

Create Custom Tenants

Most production deployments create one or more custom tenants.

Examples include:

Finance
Engineering
HR
Customer-A
Customer-B
Customer-C

Each tenant can maintain its own:

• Dashboards
• Saved searches
• Index patterns
• Visualizations
• Reports
• Discover settings

This allows different teams or customers to customize their workspace without affecting one another.

Assign Tenant Permissions

After creating tenants, assign permissions through security roles.

Typical permission levels include:

Most organizations define tenant permissions based on job responsibilities.

For example:

Following the principle of least privilege helps minimize accidental modifications while keeping sensitive dashboards isolated.

Example Configuration

The following example grants full access to the Customer-A tenant.

tenant_permissions:
  - tenant_patterns:
      - "Customer-A"

    allowed_actions:
      - "kibana_all_write"

A read-only configuration would instead use:

tenant_permissions:
  - tenant_patterns:
      - "Customer-A"

    allowed_actions:
      - "kibana_all_read"

These permissions are assigned through security roles rather than directly to users, making the configuration easier to manage as the environment grows.

Configure Dashboard Access

After tenants and permissions have been configured, users can begin accessing the Wazuh Dashboard.

The dashboard automatically displays only the resources that a user’s assigned roles allow them to access.

Tenant Selection

Users who have access to multiple tenants can choose which tenant they want to work in after signing in.

Examples include:

• Global
• Private
• Finance
• Engineering
• Customer-A
• Customer-B

Switching tenants changes the dashboards, visualizations, and saved objects displayed in the interface without requiring users to log out.

Switching Tenants

When a user switches tenants:

• Different dashboards appear.
• Different saved searches become available.
• Different visualizations are loaded.
• Tenant-specific reports become accessible.

The underlying Wazuh deployment remains unchanged; only the workspace and permissions visible to the user change.

This allows administrators and MSSP analysts to move between multiple customer environments from a single dashboard session.

Restricting Dashboard Visibility

One of the most important aspects of multi-tenancy is ensuring users cannot access dashboards that belong to other tenants.

Best practices include:

• Grant access only to required tenants.
• Avoid assigning Global Tenant access unless necessary.
• Regularly review role mappings.
• Remove unused user accounts promptly.
• Test permissions using non-administrator accounts.

These measures help prevent accidental disclosure of sensitive operational data.

Saved Objects

Saved objects are stored independently within each tenant.

These include:

• Dashboards
• Saved searches
• Reports
• Maps
• Canvas objects
• Lens visualizations

Creating or editing a saved object in one tenant does not affect any other tenant.

This separation enables each department or customer to customize its own monitoring environment.

Index Patterns

Index patterns are also tenant-specific.

For example, one tenant might define patterns such as:

wazuh-alerts-*

while another tenant may use more restrictive patterns tailored to dedicated indexes or specific business units.

Carefully managing index patterns helps ensure users query only the data they are authorized to access.

If you’re organizing indexes for large environments, see The Ultimate Wazuh Indexer Guide and How to Configure Wazuh Index State Management (ISM).

Visualizations

Visualizations, including charts, tables, timelines, and heat maps, are stored independently within each tenant.

This allows each organization or department to build dashboards focused on its own operational priorities without affecting other users.

For example:

• A SOC team may create threat detection dashboards.
• Compliance teams may build regulatory reporting dashboards.
• Executives may use high-level KPI dashboards.
• MSSP customers may receive customized security reports.

By combining tenant isolation with role-based access control and index permissions, organizations can securely operate a single Wazuh deployment while providing each user with a tailored and isolated dashboard experience.

Restrict Index Access

Creating tenants alone does not secure your Wazuh deployment.

Users must also be restricted to the appropriate OpenSearch indexes.

Even if a user only sees a single tenant in the Wazuh Dashboard, improperly configured index permissions could still allow unauthorized searches if security roles are too permissive.

For this reason, index permissions should always be configured alongside tenant permissions.

Grant Access to Specific Indexes

The safest approach is to grant access only to the indexes users actually require.

For example, a SOC analyst may only need access to alert indexes:

wazuh-alerts-*

An administrator might require additional permissions for:

• System indexes
• Monitoring indexes
• Snapshot repositories
• Security indexes

Meanwhile, an executive dashboard user may only require read access to alert indexes.

Avoid broad wildcard permissions such as:

*

or

*alerts*

unless absolutely necessary.

Restricting index access reduces the attack surface and minimizes accidental data exposure.

Prevent Unauthorized Access

Unauthorized access generally occurs because of overly permissive roles rather than flaws in multi-tenancy itself.

Common mistakes include:

• Granting wildcard index permissions
• Assigning administrator roles to regular users
• Mapping users to multiple conflicting roles
• Forgetting to remove obsolete permissions
• Leaving temporary test accounts enabled

Regular permission reviews help identify these issues before they become security risks.

The Open Worldwide Application Security Project identifies broken access control as one of the most critical web application security risks, reinforcing the importance of enforcing least-privilege permissions throughout the platform.

Verify Permissions

After assigning index permissions, verify that every role behaves as expected.

Recommended validation steps include:

• Confirm authorized indexes are searchable.
• Verify unauthorized indexes are hidden.
• Test access using non-administrator accounts.
• Review OpenSearch Security logs for denied requests.
• Ensure API queries return only authorized results.
• Confirm dashboards display expected data.

Do not rely solely on administrator accounts during testing, since administrators typically bypass many permission restrictions.

Testing Access Controls

Perform permission testing before placing the environment into production.

A practical testing checklist includes:

Testing should also be repeated whenever:

• New roles are created
• Authentication providers are modified
• Tenants are added
• Index permissions change
• Wazuh or OpenSearch is upgraded

Example Configuration

The following example grants read-only access to Wazuh alert indexes.

index_permissions:
  - index_patterns:
      - "wazuh-alerts-*"

    allowed_actions:
      - "read"

A role requiring write access could instead use:

index_permissions:
  - index_patterns:
      - "wazuh-alerts-*"

    allowed_actions:
      - "crud"

Avoid granting broader permissions unless users genuinely require them.

Integrate External Authentication

Although internal users work well for small deployments, most production environments authenticate users through an enterprise identity provider.

External authentication simplifies account management by allowing users to log in with their existing corporate credentials while administrators manage permissions centrally.

OpenSearch Security supports several authentication mechanisms that integrate directly with Wazuh.

LDAP

LDAP remains one of the most common authentication methods for enterprise Wazuh deployments.

Benefits include:

• Centralized user management
• Existing organizational groups
• Simplified onboarding
• Automatic account removal
• Central password policies

When a user authenticates, LDAP provides the backend groups that OpenSearch Security maps to roles.

If you’re configuring LDAP integration, see How to Configure Wazuh LDAP Authentication.

Active Directory

Organizations using Microsoft environments commonly authenticate against Active Directory.

Advantages include:

• Native Windows integration
• Group-based authorization
• Kerberos support
• Centralized account lifecycle management
• Enterprise password policies

Instead of maintaining separate Wazuh accounts, administrators simply assign users to Active Directory security groups.

SAML

SAML enables Single Sign-On (SSO) with enterprise identity providers such as:

• Microsoft Entra ID
• Okta
• Ping Identity
• OneLogin
• Keycloak

Benefits include:

• Single Sign-On
• Multi-factor authentication
• Centralized authentication
• Simplified user experience
• Reduced password management

SAML is particularly useful for organizations with multiple enterprise applications using the same identity provider.

OpenID Connect (OIDC)

OpenID Connect is a modern authentication protocol built on OAuth 2.0.

Many cloud identity providers support OIDC, including:

• Microsoft Entra ID
• Google Workspace
• Okta
• Auth0
• Keycloak

OIDC offers several advantages:

• Modern token-based authentication
• Easy cloud integration
• Single Sign-On
• Support for API authentication
• Strong integration with modern identity platforms

Role Mapping

Regardless of the authentication method, users must still be mapped to OpenSearch security roles.

The authentication flow typically follows this process:

User
   │
   ▼
Identity Provider
   │
   ▼
Backend Role
   │
   ▼
OpenSearch Role
   │
   ▼
Tenant Permissions
   │
   ▼
Dashboard Access

This separation allows organizations to manage authentication and authorization independently.

Group Synchronization

One of the biggest advantages of external authentication is automatic group synchronization.

For example:

AD Group:
SOC_Analysts

↓

Backend Role:
soc_analysts

↓

Security Role:
SOC Analyst

↓

Tenant:
Operations

Adding a new employee to the SOC_Analysts directory group automatically grants the appropriate Wazuh permissions after the next authentication.

Likewise, removing the user from the directory group immediately revokes those permissions.

This greatly reduces administrative effort in large organizations.

Automatic Tenant Assignment

When backend roles are mapped correctly, tenant access is assigned automatically during login.

For example:

Users no longer need manual permission assignments inside Wazuh, making onboarding and offboarding considerably easier.

Verify Multi-Tenant Isolation

After configuring users, roles, tenants, and index permissions, the final step is verifying that isolation works exactly as intended.

This validation is essential before granting production access to departments or customers.

Testing should always be performed using non-administrator accounts because administrator roles often bypass restrictions that ordinary users cannot.

Login Testing

Begin by testing each user role individually.

For every account, verify that:

• Authentication succeeds.
• The correct tenant is available.
• Unauthorized tenants do not appear.
• Dashboard access matches assigned permissions.
• Login errors are absent.

Documenting these tests makes future audits and troubleshooting much easier.

Dashboard Isolation

Next, verify that dashboards remain isolated between tenants.

For example:

1. Create a dashboard in Customer-A.
2. Log in as a Customer-B user.
3. Confirm the dashboard is not visible.
4. Repeat for every tenant.

Shared dashboards should only appear in tenants where access has been intentionally granted.

Index Access Validation

Validate that users can search only authorized indexes.

Examples include:

• Search wazuh-alerts-* and confirm expected results.
• Attempt to query an unauthorized index.
• Verify that access is denied.
• Confirm Discover displays only permitted index patterns.

Review OpenSearch Security audit logs if unexpected access is observed.

Saved Object Separation

Saved objects should remain completely isolated between tenants.

Create several objects in one tenant, including:

• Dashboards
• Visualizations
• Saved searches
• Reports
• Index patterns

Then log in using another tenant and verify none of those objects are visible.

This confirms that tenant isolation is functioning correctly within the Wazuh Dashboard.

User Permission Verification

Finally, confirm that each role has only the permissions it requires.

A simple verification matrix can help:

As your environment evolves, periodically repeat these validation tests after:

• Creating new tenants
• Modifying security roles
• Changing authentication providers
• Updating OpenSearch Security policies
• Upgrading Wazuh or OpenSearch

Regular verification helps ensure that permission changes do not unintentionally expose sensitive security data or disrupt user access.

Security Best Practices

A properly configured Wazuh multi-tenant environment provides strong logical separation, but security depends heavily on how users, roles, authentication, and permissions are managed.

Following security best practices helps prevent unauthorized access, reduces configuration mistakes, and ensures that each tenant remains isolated.

Apply Least Privilege

Least privilege should be the foundation of every Wazuh multi-tenancy deployment.

Users should receive only the permissions required to perform their responsibilities.

For example:

• SOC analysts should access alerts but not manage security settings.
• Executives should view dashboards but not modify saved objects.
• Auditors should have read-only permissions.
• Customers should only access their own tenant and indexes.

Avoid assigning broad roles such as administrator unless absolutely necessary.

Regularly review permissions to identify:

• Unused privileges
• Excessive index access
• Old user accounts
• Temporary permissions that are no longer required

A smaller permission footprint reduces the impact of compromised credentials.

Separate Administrative Accounts

Administrators should maintain separate accounts for administrative and daily activities.

Avoid using administrator accounts for:

• Searching alerts
• Creating dashboards
• Routine investigations
• General monitoring

Instead, use:

• A standard analyst account for daily work
• A privileged administrator account for configuration changes

Benefits include:

• Better auditing
• Reduced accidental changes
• Lower risk from credential theft
• Clearer accountability

For example:

john.smith
    └── SOC Analyst

john.smith-admin
    └── Wazuh Administrator

Use Strong Authentication

Strong authentication protects the identity layer of your Wazuh deployment.

Recommended practices include:

• Enforce strong password requirements
• Disable unused accounts
• Remove default credentials
• Use centralized authentication where possible
• Require unique accounts for every user

Never share accounts between analysts or administrators.

Shared credentials make it difficult to determine:

• Who performed an action
• When a change occurred
• Which user accessed sensitive data

Enable Multi-Factor Authentication (MFA)

MFA provides an additional security layer beyond passwords.

Even if credentials are compromised, attackers must still provide another authentication factor.

Common MFA methods include:

• Hardware security keys
• Authentication applications
• Push notifications
• One-time passwords

MFA is especially important for:

• Administrator accounts
• MSSP operators
• Remote users
• Users accessing sensitive customer environments

When integrating Wazuh with enterprise identity providers, MFA can typically be enforced through the authentication platform rather than directly inside Wazuh.

Audit User Activity

Monitoring user activity helps detect:

• Unauthorized access attempts
• Suspicious account behavior
• Incorrect role assignments
• Configuration changes

Audit important events such as:

• User creation
• Role changes
• Tenant modifications
• Authentication failures
• Permission changes

Reviewing security logs regularly can identify configuration issues before they become security problems.

Review Role Assignments Regularly

Role assignments should not be treated as permanent.

Over time, users change responsibilities, leave teams, or require different access.

Perform regular access reviews:

• Remove inactive users
• Verify tenant memberships
• Review administrator privileges
• Remove unused roles
• Validate backend group mappings

A quarterly access review is a common practice for enterprise environments.

Use External Identity Providers

For larger deployments, external authentication is usually preferable to manually managing internal Wazuh users.

Benefits include:

• Centralized account lifecycle management
• Existing password policies
• Automatic group synchronization
• Easier employee onboarding
• Faster account removal

Common identity providers include:

• LDAP
• Active Directory
• SAML providers
• OpenID Connect providers

External authentication also reduces the risk of inconsistent permissions because access can be controlled through existing organizational groups.

Rotate Credentials

Credentials should be rotated regularly, especially for:

• Administrator accounts
• Service accounts
• API users
• Automation accounts

Recommended practices include:

• Use password managers
• Avoid hardcoded credentials
• Rotate compromised credentials immediately
• Remove unused service accounts
• Document credential ownership

Service accounts used for automation should have dedicated credentials and minimal permissions.

Performance Considerations

While Wazuh multi-tenancy provides logical isolation, large deployments require careful planning.

Performance can be affected by:

• Number of tenants
• Number of users
• Dashboard objects
• Authentication providers
• Index design
• OpenSearch cluster resources

Large Numbers of Tenants

Small numbers of tenants typically have minimal performance impact.

However, large MSSP deployments with hundreds or thousands of tenants require additional planning.

Potential challenges include:

• Increased number of saved objects
• More complex permission evaluation
• Larger security configuration files
• More frequent dashboard queries

For large environments:

• Use consistent tenant naming conventions.
• Automate tenant creation.
• Standardize dashboards.
• Avoid unnecessary duplicate objects.
• Monitor OpenSearch performance metrics.

If you are building a large Wazuh deployment, see The Complete Wazuh Cluster Architecture Guide.

Dashboard Object Scaling

Every tenant can contain:

• Dashboards
• Visualizations
• Saved searches
• Index patterns
• Reports

Large numbers of objects increase dashboard management overhead.

Best practices include:

• Create reusable templates.
• Avoid duplicate dashboards.
• Remove unused objects.
• Standardize reporting dashboards.
• Limit write permissions.

For example, instead of allowing every customer to create hundreds of dashboards, provide approved dashboard templates.

Role Evaluation Overhead

Every request must be evaluated against:

• User identity
• Assigned roles
• Backend roles
• Tenant permissions
• Index permissions

Large numbers of roles can make permission management more complex.

Avoid creating thousands of highly specific roles unless necessary.

A better approach is:

User Group
     ↓
Backend Role
     ↓
Reusable Security Role
     ↓
Tenant Permissions

This provides scalability while keeping authorization logic manageable.

Index Permission Performance

Index permissions directly affect how OpenSearch processes user queries.

Complex permission rules can increase authorization overhead.

Recommendations:

• Use predictable index patterns.
• Avoid excessive wildcard rules.
• Keep role definitions simple.
• Use dedicated indexes only when necessary.

For large-scale index planning, see The Ultimate Wazuh Indexer Guide.

Authentication Latency

External authentication introduces additional communication between Wazuh and the identity provider.

Potential delays can occur because of:

• LDAP searches
• Network latency
• Identity provider availability
• Group synchronization

Improve authentication performance by:

• Using efficient LDAP filters.
• Indexing directory attributes.
• Reducing unnecessary group lookups.
• Using highly available identity providers.

OpenSearch Cluster Sizing

Multi-tenancy increases the importance of proper OpenSearch sizing.

Consider:

• Number of users
• Number of tenants
• Alert volume
• Dashboard usage
• Retention requirements
• Query frequency

Monitor:

• CPU usage
• JVM heap utilization
• Disk usage
• Query latency
• Cluster health

If your cluster experiences resource pressure, see:

• How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes 
• How to Fix circuit_breaking_exception Data Overloads in Wazuh Indexer 

Common Multi-Tenancy Problems and Solutions

Even with correct planning, administrators may encounter issues when configuring Wazuh multi-tenancy.

Most problems are caused by:

• Incorrect role mappings
• Missing permissions
• Authentication issues
• Tenant configuration errors
• Index access restrictions

User Cannot See Assigned Tenant

Symptoms

• User logs in successfully.
• Expected tenant does not appear.
• Only Private Tenant is available.

Common Causes

• Role mapping was not applied.
• Tenant permissions were not assigned.
• User belongs to the wrong backend role.
• Dashboard session was not refreshed.

Solutions

Verify:

1. User authentication details.
2. Backend role assignments.
3. OpenSearch role mappings.
4. Tenant permissions.

Example:

tenant_permissions:
  - tenant_patterns:
      - "Customer-A"
    allowed_actions:
      - "kibana_all_read"

After changing permissions, log out and log back in to refresh the security context.

Permission Denied Errors

Symptoms

Users receive:

• 403 Forbidden errors
• Authorization failures
• Empty dashboard pages

Common Causes

• Missing index permissions
• Incorrect role assignments
• Insufficient tenant privileges

Solutions

Check:

• User roles
• Index permissions
• Tenant permissions
• OpenSearch Security logs

Ensure the role contains both:

• Dashboard permissions
• Index permissions

A user may see a tenant but still be unable to access data if index permissions are missing.

Dashboards Missing After Login

Symptoms

Users can access Wazuh Dashboard but expected dashboards are unavailable.

Common Causes

• Dashboard was created in another tenant.
• User selected the wrong tenant.
• Saved objects were never imported.
• Tenant permissions are incorrect.

Solutions

Verify:

• Active tenant selection
• Saved object ownership
• Tenant access permissions

Dashboards created inside the Global Tenant will not automatically appear inside custom tenants.

Users Can Access Unauthorized Data

Symptoms

Users can view alerts belonging to another organization or department.

Common Causes

• Overly broad index permissions
• Wildcard index access
• Incorrect role mappings
• Shared administrator roles

Solutions

Review:

• Index patterns
• Role assignments
• Backend groups
• Tenant permissions

Avoid permissions such as:

*

when users only require access to specific data.

Role Mappings Not Applied

Symptoms

• User authenticates successfully.
• Expected permissions are missing.
• Backend roles appear incorrect.

Common Causes

• Incorrect backend role name
• Identity provider attribute mismatch
• Cached authentication information
• Incorrect role mapping syntax

Solutions

Verify the authentication response and confirm that the backend role matches the configured mapping.

Example:

backend_roles:
  - "soc_analysts"

must match the exact group returned by LDAP, Active Directory, or another provider.

LDAP Group Mapping Issues

Symptoms

• Users authenticate.
• Directory groups are not converted into Wazuh roles.

Common Causes

• Incorrect LDAP search filters
• Wrong group attribute
• Missing group permissions
• Incorrect base DN configuration

Solutions

Check:

• LDAP configuration
• Group membership attributes
• Backend role extraction
• OpenSearch Security mappings

For LDAP troubleshooting, see How to Configure Wazuh LDAP Authentication.

Tenant Switching Problems

Symptoms

• Tenant selector is missing.
• Switching tenants fails.
• Users are redirected back to the default tenant.

Common Causes

• User only has one tenant.
• Tenant permissions are incomplete.
• Browser session contains stale authentication data.

Solutions

Try:

• Logging out and back in.
• Clearing browser cache.
• Reviewing tenant role permissions.
• Checking OpenSearch Security logs.

Saved Objects Not Visible

Symptoms

Users cannot see:

• Dashboards
• Visualizations
• Saved searches

Common Causes

• Objects belong to another tenant.
• User lacks tenant permissions.
• Objects were imported into the wrong workspace.

Solutions

Verify:

• Active tenant
• Saved object location
• Tenant permissions

Remember that dashboards and visualizations are tenant-specific.

Creating an object in one tenant does not make it available everywhere.

Properly configured tenants, roles, and index permissions ensure that Wazuh can support multiple organizations or departments securely while maintaining centralized management.

Monitoring Multi-Tenant Environments

Once Wazuh multi-tenancy is deployed, ongoing monitoring is essential to ensure that tenant isolation, permissions, and authentication controls continue working correctly.

A secure multi-tenant environment should not only prevent unauthorized access but also provide visibility into:

• Who accessed the platform
• Which resources were accessed
• Which permissions were changed
• Whether users attempted unauthorized actions

Continuous monitoring helps identify configuration mistakes, compromised accounts, and abnormal user behavior.

Audit Logs

Audit logs provide visibility into security-related actions performed within the Wazuh environment.

Important events to monitor include:

• User creation and deletion
• Role changes
• Tenant permission updates
• Index permission modifications
• Authentication configuration changes
• Security plugin configuration updates

Audit logging is especially important in MSSP environments where multiple customers share the same infrastructure.

Administrators should retain audit records for:

• Security investigations
• Compliance requirements
• Access reviews
• Incident response

Authentication Logs

Authentication logs show how users interact with the Wazuh platform.

Monitor events such as:

• Successful logins
• Failed login attempts
• Invalid credentials
• Disabled accounts attempting access
• Authentication provider failures

Common indicators of suspicious activity include:

• Multiple failed login attempts
• Login attempts from unusual locations
• Repeated authentication failures against privileged accounts

For environments using LDAP or Active Directory, authentication logs can help identify synchronization problems between the identity provider and Wazuh.

If you are integrating centralized authentication, see How to Configure Wazuh LDAP Authentication.

Failed Authorization Attempts

Authentication confirms who a user is. Authorization determines what that user can access.

Failed authorization events can indicate:

• Incorrect role assignments
• Misconfigured permissions
• Attempted unauthorized access
• Compromised user accounts

Examples include:

• A customer attempting to access another customer’s tenant
• An analyst attempting to modify security settings
• A user querying restricted indexes

Reviewing authorization failures helps administrators identify both security threats and configuration problems.

Dashboard Usage

Monitoring dashboard activity provides insight into how users interact with each tenant.

Track:

• Frequently accessed dashboards
• Created visualizations
• Modified saved searches
• Export activity
• Report generation

Dashboard usage monitoring can help identify:

• Unused dashboards that can be removed
• Popular security views that should become templates
• Unexpected user behavior

For large deployments, standardizing dashboards across tenants reduces maintenance overhead.

Index Access Monitoring

Index access monitoring is critical because the Wazuh Indexer contains the underlying security data.

Monitor:

• Which users query specific indexes
• Failed index access attempts
• Changes to index permissions
• Unusual query activity

Important indexes may include:

wazuh-alerts-*
wazuh-archives-*
wazuh-monitoring-*

Ensure that users only access indexes required for their role.

For larger deployments, review your storage and indexing strategy using:

• The Ultimate Wazuh Indexer Guide 
• How to Manage Wazuh Storage 

Permission Audits

Regular permission audits ensure that access controls remain accurate as your organization changes.

During an audit, review:

• User accounts
• Assigned roles
• Backend role mappings
• Tenant permissions
• Index permissions
• Administrator privileges

Recommended review schedule:

Remove:

• Inactive users
• Unused roles
• Temporary access permissions
• Legacy tenant assignments

A permission model that is accurate today may become overly permissive over time as users change responsibilities.

Real-World Example

A managed security service provider (MSSP) manages security monitoring for hundreds of customers using a single Wazuh deployment.

Instead of deploying separate Wazuh environments for every customer, the MSSP builds a centralized multi-tenant architecture.

The environment consists of:

• A Wazuh Manager cluster
• A Wazuh Indexer cluster
• A Wazuh Dashboard deployment
• OpenSearch Security enabled for access control

The MSSP’s goal is to allow customers to view their own security data while preventing customers from accessing any other organization’s information.

Creating Customer Tenants

The security team creates a dedicated tenant for each customer.

Example:

Customer-A
Customer-B
Customer-C
Customer-D

Each tenant contains:

• Customer-specific dashboards
• Saved searches
• Visualizations
• Reports
• Index patterns

Customer-A administrators can customize their dashboards without affecting Customer-B or Customer-C.

Configuring Customer Roles

The MSSP creates reusable security roles.

Example:

Customer Analyst Role

Permissions:
- View dashboards
- Search alerts
- Create saved searches
- Access Customer-A data only

Additional roles may include:

Customer Read Only

Permissions:
- View dashboards
- Read alerts
- No editing privileges

and:

MSSP Administrator

Permissions:
- Manage all tenants
- Manage users
- Configure roles
- Perform maintenance

Implementing Role Mappings

Instead of manually creating hundreds of user accounts, the MSSP integrates Wazuh with LDAP.

Example:

LDAP Group:

Customer-A-Security-Team


↓

Backend Role:

customer_a_users


↓

OpenSearch Role:

Customer-A-Analyst


↓

Tenant:

Customer-A

When a new employee joins Customer-A’s security team, administrators only need to add the employee to the correct LDAP group.

The user automatically receives the correct Wazuh permissions.

Restricting Index Access

The MSSP ensures customers can only query their own security data.

For example:

Customer-A users:

customer-a-alerts-*

Customer-B users:

customer-b-alerts-*

The OpenSearch Security plugin prevents Customer-A users from querying Customer-B indexes.

Even though all customers share the same Wazuh infrastructure, the data remains logically separated.

Customer Access Experience

When Customer-A logs in:

They see:

• Customer-A dashboard
• Customer-A alerts
• Customer-A saved searches
• Customer-A visualizations

They cannot see:

• Customer-B dashboards
• Customer-B alerts
• Customer-B saved objects

Meanwhile, the MSSP security operations team maintains centralized access across all tenants.

SOC analysts can:

• Investigate alerts across customers
• Maintain detection rules
• Manage integrations
• Monitor overall platform health

without exposing customer data between tenants.

Centralized Administration Benefits

This architecture allows the MSSP to achieve:

• Lower infrastructure costs
• Centralized upgrades
• Consistent security monitoring
• Faster customer onboarding
• Simplified administration

The MSSP maintains one Wazuh platform while providing each customer with an isolated security workspace.

For highly available MSSP deployments, see The Complete Wazuh Cluster Architecture Guide.

Frequently Asked Questions

Question: What is Wazuh multi-tenancy?

Wazuh multi-tenancy allows multiple groups of users or organizations to share one Wazuh deployment while keeping dashboards, saved objects, and permissions separated.

Question: Does Wazuh support multiple tenants?

Yes. Wazuh supports multi-tenancy through the Wazuh Dashboard and OpenSearch Security features.

Tenants allow organizations to separate dashboard content and user access without requiring separate Wazuh deployments.

Question: How do tenants differ from roles?

Tenants and roles serve different purposes.

A tenant defines:

• Workspace separation
• Dashboard objects
• Saved searches
• Visualizations

A role defines:

• What users can access
• Which indexes they can query
• Which actions they can perform

Roles control permissions, while tenants provide isolated workspaces.

Question: Can multiple customers share one Wazuh deployment?

Yes.

MSSPs commonly use a single Wazuh deployment with separate tenants and permissions for each customer.

Proper configuration ensures each customer only sees their own data.

Question: How do I create a new tenant?

A new tenant is created through OpenSearch Security tenant configuration.

After creation:

1. Create or update a security role.
2. Assign tenant permissions.
3. Map users or groups to that role.
4. Verify access.

Question: Can users belong to multiple tenants?

Yes.

A user can access multiple tenants if their assigned roles grant permission.

For example, an MSSP administrator may access every customer tenant, while a customer analyst may only access one.

Question: How do I restrict access to specific indexes?

Index access is controlled through OpenSearch Security roles.

Configure:

• Index patterns
• Allowed actions
• User role mappings

Example:

wazuh-alerts-customer-a-*

only grants access to Customer-A alert data.

Question: Does multi-tenancy affect Wazuh agents?

No.

Agents continue communicating with the Wazuh Manager normally.

Multi-tenancy affects:

• Dashboard access
• Index permissions
• User authorization

It does not change how agents collect or forward events.

Question: Can LDAP groups be mapped to tenants?

Yes.

LDAP or Active Directory groups can be mapped to backend roles, which are then assigned tenant permissions.

This allows automatic tenant assignment based on organizational membership.

Question: Is multi-tenancy available in all Wazuh versions?

Multi-tenancy availability depends on the Wazuh version and the underlying OpenSearch Dashboard capabilities.

Always verify compatibility before upgrading or designing a production deployment.

Question: How do I troubleshoot tenant permission issues?

Common troubleshooting steps include:

1. Verify user role mappings.
2. Confirm tenant permissions.
3. Check index permissions.
4. Review OpenSearch Security logs.
5. Test with a non-administrator account.
6. Re-authenticate after permission changes.

Question: What is the difference between Global, Private, and Custom tenants?

Most production multi-tenant deployments rely heavily on custom tenants.

Conclusion

Wazuh multi-tenancy allows organizations to securely operate a shared security monitoring platform while maintaining logical separation between teams, departments, and customers.

By combining:

• Wazuh Dashboard tenants
• OpenSearch Security roles
• Index permissions
• Backend role mappings
• External authentication providers

organizations can build scalable security environments without managing multiple independent Wazuh deployments.

A successful multi-tenant implementation requires careful planning:

1. Define tenant boundaries.
2. Design roles based on responsibilities.
3. Restrict index access using least privilege.
4. Configure authentication and role mappings.
5. Validate isolation through testing.
6. Perform regular permission audits.

Multi-tenancy is especially valuable for MSSPs and large enterprises that need centralized administration while maintaining strict data separation.

For additional Wazuh security architecture guidance, continue with:

• How to Configure Wazuh LDAP Authentication
• Troubleshooting Wazuh RBAC
• Resolving OpenSearch Multi-Tenancy Mismatches in Wazuh Deployments 
• The Ultimate Wazuh Configuration Guide 
• The Complete Wazuh Cluster Architecture Guide

Regular reviews, security audits, and permission validation ensure your Wazuh multi-tenant environment remains secure as your organization grows.