Rubrik Basics – Multi-tenancy – Create An Organization

I covered multi-tenancy with Rubrik some time ago, but things have certainly advanced since then. One of the useful features of Rubrik CDM (and something that’s really required for Envoy to make sense) is the Organizations feature. This is the way in which you can use a combination of LDAP sources, roles, and tenant workloads to deliver a packaged multi-tenancy feature to organisations either within or external to your company. In this article I’ll run through the basics of setting up an Organization. If you’d like to see how it can be applied in a practical sense, it’s worth checking out my post on deploying Rubrik Envoy.

It starts, as these things often do, by clicking on the gear in the Rubrik CDM UI. Select Organizations (located under Access Management).

Click on Create Organization.

You’ll want to give it a name, and think about whether you want to give your tenant the ability to do per-tenant access control.

You’ll want an Org Admin Role to have particular abilities, and you might like to get fancy and add in some additional roles that will have some other capabilities.

At this point you’ll get to select which users you want in your Organization.

Hopefully you’ve added the tenant’s LDAP source to your environment already.

And it’s worth thinking about what users and / or groups you’ll be using from that LDAP source to populate your Organization’s user list.

You’ll also need to consider which role will be assigned to these users (rather than relying on Global Admins to do things for tenants).

You can then assign particular resources, including VMs, vApps, and so forth.

You can also select what SLA Domains the Organization has access to, as well as Archival locations, and replication targets and sources. This becomes important in a multi-tenanted environment as you don’t want folks putting data where they shouldn’t.

At this point you can download the Rubrik Envoy OVA, deploy it, and connect it to your Organization.

And then you’re done. Well, normally you would be, but I didn’t select a whole lot of objects in this example. Click Finish and you’re on your way.

Assuming you’ve assigned your roles correctly, when your tenant logs in, he or she will only be able to see and control resources that belong to that particular Organization.


Rubrik Basics – Multi-tenancy

I’ve been doing some work with Rubrik in our lab and thought it worth covering some of the basic features that I think are pretty neat. In this edition of Rubrik Basics, I thought I’d quickly cover off how to get started with the multi-tenancy feature. You can read a little about it here. And yes, I know, some of the Rubrik documentation doesn’t hyphenate the word. But this is the hill I’m dying on apparently.


Multi-tenancy and Role-based Access

Multi-tenancy means a lot of different things to a lot of different people. In the case of Rubrik, multi-tenancy is an extension of the RBAC scheme enables a central organisation to delegate administrative capabilities to multiple tenant organisations. That is, you’ll likely have one global administrator (probably the managed service provider) looking after the Rubrik environment and carving it up for use by a number of different client organisations (tenants).

Each tenant organisation has a subset of administrative privileges defined by the global organisation. A tenant’s administrative privileges are also specified on a per-organisation basis. The administrators of the tenant can then go and do their thing independently of the cluster administrator. Because Rubrik supports multiple Active Directory domains, you can still use AD authentication on a per-tenant basis.


A Rubrik cluster can have one central organisation and any number of tenant organisations. An organisation is a collection of the following elements:

  • Protected objects
  • Replication and archival targets
  • SLA Domains
  • Local users
  • Active Directory users and groups
  • Service credentials
  • Reports


The Impact

SLA Domains are the mechanism used to protect objects in the Rubrik environment. In the case of multi-tenancy, SLA Domains are impacted by virtue of which organisation creates them. If the SLA Domain is created outside of a tenant organisation (and assigned to that organisation), it cannot be altered by the users or AD groups of the tenant organisation. Those that are created within a tenant can be modified by that tenant.

Note also that a Tenant Organisation does not inherit Guest OS Credentials from the Global Organisation. If you want to use the Guest OS Credentials of the global org you’ll need to assign those on a per-tenant basis.


Other Thoughts

When it comes to offering products as a service, there’s a bit more to multi-tenancy in terms of network connectivity, reporting, QoS, and other things like that. But the foundation, in my opinion, is the ability to create tenants organisations on the platform and have those remain independent of each other. The key to this is tying multi-tenancy in to your RBAC scheme to ensure that the rules of the tenancy are being observed. Once you have that working correctly, it becomes a relatively simple exercise to start to add features to the platform that can take advantage of those rules.

Rubrik introduced multi-tenancy into Rubrik CDM with 4.1, and it seems to be a pretty well thought out implementation. It’s not a feature that enterprise bods are interested in, but it’s certainly something that service providers require to be able to satisfy their customers that the right people will be touching the right stuff. I’m looking forward to testing out some more of these features in the near future.