Wazuh Kubernetes Deployment with Multi-Tenancy and RBAC

[João Castanheira]

In order to implement Wazuh as a SocaaS for multiple clients, is it feasible to deploy Wazuh with k8s, while also using the multi-tenancy and RBAC features in order to split the indexes by client, so each client can only see the indexes relevant to him?

For example, what I want is having Wazuh deployed in my network via k8s so I can make use of the high-availability, self-healing, the rollouts and rollbacks features and then create agent groups for each client, having rules that identify client-specific technologies and then give clients accounts that only allow them to read their specific indexes via multitenancy and RBAC ?

Is it possible? 

Also architecture-wise I was thinking about 1 manager, 1 dashboard (centralized) and then workers per client and indexers per client.

[Carlos Anguita López]

From a deployment perspective, running Wazuh on Kubernetes is feasible and allows you to benefit from high availability, self-healing, and controlled rollouts/rollbacks, especially for stateless components such as the Dashboard and the API. Stateful components like the Wazuh Manager and the Indexer require persistent storage and careful planning, as Wazuh is not fully cloud-native.

Regarding multi-tenancy, check this documentation in order to enable multi-tenancy: documentation.wazuh.com/current/user-manual/wazuh-dashboard/multi-tenancy.html.

You can separate clients by using agent groups per customer, client-specific rules and decoders, and index naming conventions. Combined with RBAC (check this documentation: documentation.wazuh.com/current/user-manual/api/rbac/index.html), it is possible to create users and roles that only have read access to the indices belonging to a specific client, so each customer can only see their own data in the Dashboard.

From an architectural point of view, a single Wazuh manager cluster (manager + workers) shared across tenants is the usual approach. Workers are designed for load distribution and scalability, not for tenant isolation. Running dedicated indexers per client is technically possible, but it significantly increases operational complexity and cost, especially in a Kubernetes environment. Most SOCaaS deployments rely on a shared indexer cluster with per-client indices and RBAC instead.

In summary, your proposed model is achievable using Kubernetes, agent grouping, index separation, and RBAC, and it is a common pattern for SOCaaS deployments.

You could try creating this environment and see what problems you encounter.

[João Castanheira]

Can I decouple storage from the application?

As in, can I have a server with all my index data and have the pods in another machine ? Will Wazuh work as intended ?
Thanks in advance

[Carlos Anguita López]

It depends largely on the storage architecture and the hardware you plan to use.

In Kubernetes, Wazuh components that require persistence (mainly the Indexer and the Manager) need their data to be mounted as Persistent Volumes (PVs) inside the corresponding pods.

From Wazuh’s point of view, it does not matter whether the underlying storage is local to the node or provided by an external storage system, as long as it is exposed to the pods as persistent storage.

However, the implementation details are entirely dependent on your infrastructure design.

In short:

• Wazuh requires persistent data to be mounted as PVs in the relevant pods.
• How those PVs are implemented (local disks, shared storage, external storage systems) is an infrastructure decision.