Multi-tenancy in MAAS

In this blog post, we are going to introduce the concept of multi-tenancy in MAAS. This allows operators to have different groups of users own a group of resources (machines) without ever even knowing about other groups of users enabling enhanced machine utilisation.

A common use case for medium and large-scale environments is to provide a different set of machines for different users or groups of users. MAAS has historically approached this by allowing users to pre-reserve machines (allocate) for later use. However, as of MAAS 2.4 we introduced the concept of resource pools.

Resource pools and role-based access control

Resource pools are a new way to organise your physical and virtual resources. A resource pool is effectively a bucket in which one or more machines can be placed. A machine can only be in one resource pool.

Figure 1. MAAS resource pools.

But now that you have organised your machines, how do you go about assigning users or groups to the different resource pools and preventing users from seeing resources that are assigned to someone else? Well, this is done with RBAC.

Role-based access control (RBAC) is supported in MAAS as an external micro-service that provides this functionality. The Canonical RBAC service allows administrators to select which users or groups of users can have access to a given resource pool, and the role that they can play within the resource pool itself.

Figure 2. RBAC service.

RBAC provides four roles that give the flexibility in multi-tenant environments:

  • Administrator – Maps to the current administrative user in MAAS.
  • Operator – Provides administrative permissions in the context of a resource pool.
  • User – Maps to the current non-administrative user of MAAS.
  • Auditor – Can only read information.

As MAAS can organise its physical and virtual resources in resource pools and prevent access to those resources via RBAC, what about authentication?  Where do users or user groups come from?

To provide authentication, MAAS and RBAC integrates with Candid, the Canonical identity manager service. Candid is a centralised authentication service that integrates with LDAP, Active Directory, SSO, and others. For MAAS, Candid provides LDAP authentication which is the source of users or user groups.

This allows administrators to continue to use their current authentication systems and seamlessly integrate them with MAAS and RBAC.

So, multi-tenancy?

As we have learnt, MAAS achieves multi-tenancy by making use of resource pools, RBAC and LDAP (with Candid). With this, administrators in MAAS can ensure certain users or groups within their organisation have access to only one or multiple resource pools.

But, how is this really multi-tenancy? It is because users (or user groups) will only be able to access the resources within the resource pools they have access to; they won’t be able to see that other resource pool exists. This provides complete separation making MAAS very flexible for large-scale environments or SMBs.  

For more information please contact us.


Ubuntu cloud

Ubuntu offers all the training, software infrastructure, tools, services and support you need for your public and private clouds.

Newsletter signup

Select topics you’re
interested in

In submitting this form, I confirm that I have read and agree to Canonical’s Privacy Notice and Privacy Policy.

Related posts

Migrating the MAAS UI from AngularJS to React

MAAS (metal as a service), is a Canonical product which allows for very fast server provisioning and data centre management. Around 2014, work began to build...

Yahoo! Japan builds their IaaS environment with Canonical

Yahoo! Japan, originally formed as a joint venture between Yahoo! and SoftBank, is one of the most popular internet advertising, search engines and e-commerce...

Announcing the new IBM LinuxONE III with Ubuntu

This is a guest blog by Kara Todd, Director, Linux, IBM Z and LinuxONE Enterprises today need a highly secure, and flexible system to support their...