Veeam v13 Tenant Isolation Patterns for MSPs

Veeam v13 Tenant Isolation Patterns for MSPs

Veeam v13 Series | Component: VBR RBAC, Repository Architecture | Audience: MSP Architects, Service Provider Engineers, Infrastructure Leads

1. The Problem: Multi-Tenant VBR Without Cloud Connect

Many MSPs run a single VBR server (or a small number of them) protecting workloads across multiple customers. Not every MSP deploys Cloud Connect. Some manage backup jobs directly against customer infrastructure using site-to-site VPNs, remote proxies, or agent-based protection. In that model, every customer's backup jobs, restore points, and metadata coexist on the same VBR instance.

The question is how to prevent Tenant A's administrator from seeing Tenant B's backup job names, VM names, restore points, and repository contents. Before v13, the answer was limited. VBR's built-in RBAC offered predefined roles (Backup Administrator, Backup Operator, Restore Operator) that applied globally. You could not scope a role to specific workloads or repositories. The only way to enforce real isolation was to deploy separate VBR instances per customer, which is expensive and operationally painful.

v13 changes this with the enhanced RBAC framework. Custom roles with scoped permissions let you define exactly which workloads, repositories, and restore operations each user can access. It is not full Cloud Connect multi-tenancy, but it covers the operational middle ground that most managed backup MSPs actually need.

2. Architecture Options

There are four ways to handle multi-tenant backup with Veeam, ranging from full isolation to shared infrastructure with logical separation.

This article focuses on Model 3: shared VBR with v13 RBAC scoping. This is the model that most small and mid-size MSPs are actually running, and v13 finally gives it the access control framework it needed.

3. v13 Enhanced RBAC: Custom Roles with Scoped Permissions

The enhanced RBAC framework in v13 introduces the Custom Role wizard. Instead of assigning predefined roles that apply to everything, you build a role by selecting specific permissions and scoping them to specific resources.

What You Can Scope

Data Source Scope. Restrict backup permissions to specific inventory objects: individual VMs, vCenter folders, clusters, Hyper-V hosts, or protection groups. A role scoped to Tenant A's vCenter folder cannot see or back up VMs in Tenant B's folder.

Repository Scope. Restrict which backup repositories the role can target. A role can be limited to "Only Selected Backup Repositories," ensuring tenant data lands only on designated storage.

Restore Scope. Restrict what the role can restore and where it can restore to. You can limit a role to restoring only the backups it created, or only specific restore point types, or only to certain infrastructure targets.

Restore Target Scope. Restrict the infrastructure targets a role can restore to. A tenant admin can be limited to restoring only to their own vCenter or Hyper-V environment, not to the MSP's internal infrastructure or another tenant's environment.

4. Building a Per-Tenant RBAC Model

Here is a concrete implementation pattern for an MSP with five customers sharing a single VBR v13 instance.

Prerequisite: Organize Your Inventory

RBAC scoping works against inventory objects. If all your VMs are in a flat vCenter folder, you cannot scope by tenant. Before configuring RBAC, organize your infrastructure so each tenant's workloads are in their own container:

For vSphere: create a vCenter folder per tenant (e.g., Tenant-Acme, Tenant-Contoso). For Hyper-V: use separate Hyper-V hosts or tag groups. For agents: create a protection group per tenant.

Create Per-Tenant Custom Roles

1. 1Open the VBR console. Navigate to Users and Roles > Custom Roles.
2. 2Create a new custom role named Tenant-Acme-Operator.
3. 3On the Permissions page, select the operations this tenant admin can perform: view jobs, view sessions, perform restores. Exclude infrastructure management, repository configuration, and job creation if the MSP controls all jobs.
4. 4On the Data Source Scope page, select "Only Selected Data Sources" and choose the Tenant-Acme vCenter folder.
5. 5On the Repository Scope page, select "Only Selected Backup Repositories" and choose the repository assigned to Acme.
6. 6On the Restore Scope page, restrict restores to "Only backups created by this user" or "All backups in selected repositories" depending on your operational model.
7. 7On the Restore Target Scope, limit restore targets to Acme's infrastructure only.
8. 8Finish the wizard. Assign the role to the Acme admin's user account or AD group.

Repeat for each tenant. Each tenant gets their own custom role scoped to their own inventory, repositories, and restore targets.

SSO Integration

v13 supports SAML 2.0 SSO with identity providers like Microsoft Entra ID and Okta. This means you can federate tenant admin logins through their own identity provider, apply MFA through the IdP, and map the authenticated identity to the scoped custom role in VBR. No shared passwords. No local Veeam accounts for tenant access. The tenant admin logs in with their corporate credentials and sees only their scoped environment.

5. Repository Isolation Strategies

RBAC controls what a user can see and do. Repository isolation controls where data physically lands. Both matter for a defensible multi-tenant architecture.

Option A: Separate Repository Per Tenant

Create a dedicated backup repository for each tenant. This is the cleanest isolation. Each tenant's data is on its own storage path (or its own LUN/volume). RBAC scopes the role to only that repository. Even if RBAC had a bug, the data is physically separated.

The tradeoff is storage utilization. Dedicated repositories per tenant mean you cannot share free space across customers. You over-provision to account for growth, and some repositories sit half-empty while others are tight.

Option B: Shared Repository with Per-Job Folder Structure

Use a single large repository but create backup jobs named with a tenant prefix (e.g., ACME-Daily-Backup, CONTOSO-Daily-Backup). VBR creates a folder per job inside the repository. RBAC scoping prevents users from seeing jobs they do not have access to.

This is more storage-efficient but less physically isolated. If someone accesses the repository server directly (bypassing VBR), all tenant data is on the same file system. For most MSPs this is acceptable. For regulated environments, it is not.

Option C: SOBR with Tenant-Dedicated Extents

Build a Scale-Out Backup Repository where each extent is assigned to a specific tenant's jobs. This gives you the management simplicity of a single SOBR with the physical separation of dedicated storage. Use backup job affinity settings to pin each tenant's jobs to their extent.

6. Credential Isolation

VBR stores credentials used to connect to managed infrastructure (vCenter, Hyper-V hosts, Linux servers, Windows servers). In a multi-tenant environment, Tenant A's vCenter credentials must not be visible to Tenant B's admin.

v13's RBAC scoping handles this at the job and workload level. A user scoped to Tenant A's vCenter folder does not need and does not receive access to Tenant B's credentials. The credentials are stored in the VBR configuration database and are only used by the jobs that reference them. Tenant admins with scoped roles do not have access to Credentials and Passwords management.

For additional safety, use separate vCenter service accounts per tenant. If Tenant A's account is compromised, it does not grant access to Tenant B's vCenter. This is a defense-in-depth measure independent of VBR RBAC.

7. Network Segmentation for Tenant Traffic

RBAC and repository isolation handle the control plane and data plane within VBR. Network segmentation handles the transport layer between VBR, proxies, and customer infrastructure.

Deploy a dedicated backup proxy per tenant (or per tenant site) on the tenant's network segment. Backup data flows from the proxy to the VBR repository over a dedicated backup VLAN or VPN tunnel. This keeps tenant backup traffic isolated at the network layer and prevents cross-tenant data exposure at the transport level.

For agent-based protection, use separate protection groups per tenant with distinct management agent configurations. Agents connect to VBR over their own VPN tunnel and are scoped to their tenant's repository through job configuration.

8. Monitoring and Reporting Per Tenant

Veeam ONE can scope reports and alarms to specific jobs, VMs, or infrastructure objects. Create a Veeam ONE business view per tenant that includes only their workloads. Schedule tenant-specific backup success reports and email them to the tenant's operations team. This gives each tenant visibility into their own backup status without exposing data about other tenants.

For MSPs using VSPC, per-tenant reporting and dashboards are built into the console. VSPC aggregates data from multiple VBR instances and presents tenant-isolated views natively.

At the VBR REST API level (covered in the REST API article in this series), you can build custom monitoring dashboards that filter sessions and jobs by name prefix or job ID to produce per-tenant health reports programmatically.

9. When to Use Cloud Connect Instead

The shared-VBR-with-RBAC model works well when the MSP controls all backup jobs and the tenant needs view and restore access only. Cloud Connect is the right choice when the tenant needs to control their own backup jobs, manage their own retention, and send backups to the MSP's infrastructure from their own VBR instance. Cloud Connect provides built-in multi-tenancy with per-tenant folders, quotas, and complete data isolation in the cloud repository. Every tenant sees a logically separate repository even though the underlying storage is shared.

If your tenants are large enough to run their own VBR and they want to control their own backup policies, Cloud Connect is the correct architecture. If you are managing everything for the tenant and they just need a portal to check status and perform restores, shared VBR with v13 RBAC is simpler, cheaper, and operationally lighter.

10. When to Use VSPC on Top

Veeam Service Provider Console (VSPC) sits above individual VBR instances and provides centralized multi-tenant management. It is designed for MSPs with many customers across multiple VBR servers. VSPC provides per-tenant dashboards, license management, automated usage reporting, and REST API proxying to all managed VBR servers through a single API key.

If you are running three or fewer VBR instances and your tenant count is under 20, VSPC may be more overhead than it is worth. Manage RBAC and reporting directly in VBR and Veeam ONE.

If you are running a dozen VBR instances across multiple data centers with 50+ tenants, VSPC is not optional. The centralized license pool, the single-pane-of-glass monitoring, the REST API proxying, and the automated billing reports become essential at that scale.