learn-cyber · lesson 7 · multi-tenancy

Walls between clients

Grouping organized each hotel's machines. Now build the access-control walls so every client — and every analyst — sees only the data they're allowed to, and nothing else.

Your mission In Lesson 6 you put each hotel's agents in its own group. That kept the configuration tidy, but every login can still query everything. This lesson builds the isolation that makes selling to multiple clients trustworthy — and, for hotels under contract or regulation, mandatory: the Grand Plaza must never see the Seaside Inn's security data, and vice versa.

Two different walls

"Isolation" actually means two separate things in Wazuh, and the most common mistake is to confuse them. Keep them apart from the start:

You use both together. RBAC stops the Seaside Inn from querying Grand Plaza agents at all; tenants stop the two hotels' saved dashboards and reports from bleeding into each other. Let's take each in turn.

RBAC: who can touch which agents

RBAC — Role-Based Access Control — governs the Wazuh API, which is the gate everything goes through. Its model has three pieces that snap together:1

The default that protects you Wazuh RBAC is white-list by default: an action is denied unless a policy explicitly allows it. So a freshly created user can see nothing until you grant it. You're building up from "no access," not trying to lock down from "all access" — the safe direction.2

The killer feature: scope a policy to a hotel's group

Here's why RBAC and Lesson 6 were designed for each other. A policy's resource can be scoped to a specific agent group. So you can write a role that grants visibility and actions over only the grand-plaza agents — and nothing else in your whole deployment.3

Concretely, to give the Grand Plaza (or the junior analyst who only handles that account) read access to just their hotel:

  1. Create a policy that allows the read action on the resource "agent group grand-plaza."
  2. Bundle it into a role named, say, grand-plaza-readonly.
  3. Create an internal user for the Grand Plaza login and map the role to it.

That login can now query the Grand Plaza's agents and literally cannot query the Seaside Inn's — the white-list default denies everything the policy didn't name. The user-administration guide walks through creating internal users and mapping roles, including the case of a user scoped to only a group of agents.3

Policyallow read on group grand-plaza
→
Rolegrand-plaza-readonly bundles it
→
UserGrand Plaza login mapped to role

Dashboard tenants: who sees which saved views

RBAC walls off the data. But two clients can both have read access to their own agents and still trip over each other's saved work — a dashboard named "Front Desk Logins," a report, an index pattern — unless those are separated too. That's what dashboard multi-tenancy is for.4

The Wazuh dashboard supports tenants that separate saved objects — dashboards, visualizations, index patterns — per tenant. There are three flavors:

Give each hotel its own custom tenant — a grand-plaza tenant and a seaside-inn tenant — so their dashboards and reports stay in separate compartments. Tenancy is enabled in the dashboard's configuration file, opensearch_dashboards.yml.4

RBAC vs. tenants, one line each RBAC = which data / agents a login can access. Tenants = which saved dashboards / views a login can see. Different walls, different jobs — you put up both.

The MSSP isolation pattern

Put the last two lessons together and you have a repeatable recipe. For each hotel client you stand up three things:

Agent groupper hotel (Lesson 6)
+
RBAC rolescoped to that group
+
Dashboard tenantper hotel

Group organizes the config, the scoped role walls off the data, and the tenant walls off the saved views. Run that recipe for the Grand Plaza, run it again for the Seaside Inn, and the two are cleanly separated on one deployment.1

When one node isn't enough. At larger scale the documented advanced approach is to give each client its own Wazuh server/manager, all feeding a shared indexer cluster with index-level separation between clients. Same isolation idea, more hardware — a growth path to keep in your back pocket, not a starting point. You met single-node vs. cluster back in Lesson 2.

This is not optional polish Leaking one hotel's security data to another is a breach of trust — and possibly of contract or regulation. So test the wall: log in as the scoped grand-plaza-readonly user and confirm you cannot see Seaside Inn's agents or dashboards. Isolation you haven't verified is isolation you don't have.

Check yourself

Retrieval practice — answering from memory is what makes this stick. Don't peek back up; take the guess.

Question 1 of 3

A client login can query the Grand Plaza's agents but not the Seaside Inn's. What enforced that boundary?

RBAC controls which data and agents a login can access. A role scoped to the grand-plaza group grants action over only those agents. Tenants separate saved views; agent.conf sets monitoring.

Question 2 of 3

By default, a brand-new Wazuh user with no policies attached can do what through the API?

Wazuh RBAC is white-list by default: deny unless explicitly allowed. A fresh user sees nothing until you grant access, so you build up from "no access" — the safe direction for an MSSP.

Question 3 of 3

What three things do you stand up per hotel to isolate one client fully from another?

The MSSP isolation pattern is agent group (organizes config) + RBAC role scoped to that group (walls off data) + dashboard tenant (walls off saved views). Run that recipe per client and they stay cleanly separated.

Primary source to read next
Wazuh — RBAC (user administration). The hands-on how-to: create internal users, build roles, and map a user scoped to only a group of agents (15 min). For the model itself, read RBAC — how it works (policies, roles, white-list default) and the RBAC overview. For the views wall, read Dashboard multi-tenancy.
I'm your teacher — ask me anything. Want to walk through the exact policy JSON for grand-plaza-readonly? Unsure how RBAC on the API and a dashboard tenant line up for one client login? Curious when you'd jump to per-client managers on a shared indexer? Ask in the chat — that back-and-forth is where the real learning happens.

You just earned: the RBAC model (policies → roles → users), the white-list default, scoping a role to a hotel's agent group, dashboard tenants for separating saved views, the three-part MSSP isolation pattern, and the discipline of testing the wall before you trust it.

Up next (Lesson 8): the hotel threat model — POS, PMS, PCI-DSS, and guest Wi-Fi — so the monitoring you've learned to deploy and isolate is pointed at the right threats.

Reference: Glossary · All resources · Mission

← Lesson 6: One group per hotel · Lesson 8: The hotel threat model →

  1. Wazuh — RBAC overview (the API access-control system underpinning per-client isolation).
  2. Wazuh — RBAC how it works (policies, roles, user mapping, white-list-by-default behavior).
  3. Wazuh — RBAC (user administration) (creating internal users and mapping roles, including users scoped to only a group of agents).
  4. Wazuh — Dashboard multi-tenancy (Global, Private, and Custom tenants separating saved objects; enabled in opensearch_dashboards.yml).