Offline docs (switch to live docs)                          UI-only  CLI-only

Ensuring security in MAAS

As a MAAS administrator, you do not want secrets associated with a MAAS instance to be stored in the database. Examples of MAAS settings that contain secrets are the OMAPI key and the RPC secret.

Other examples of such secrets are:

Beginning with version 3.3, MAAS secrets are stored in HashiCorp Vault.

Summary of HashiCorp Vault

Ideally, you should consult the Vault documentation, but for convenience, we will provide a brief summary here.

Vault uses identity to protect secrets and encryption keys. The core component is the kv secrets engine, that uses key-value pairs to store arbitrary secrets within an encrypted storage extent managed by Vault. If you're interested, you may read more about secrets engines at your leisure.

Vault protects the secrets engine with a barrier view. This barrier view consists of a folder, named to a randomly-generated UUID that forms the absolute root directory for that engine. Secrets engines cannot, for example, cd .. above their UUID folder, creating barrier for what that engine can view.

Aside from this short overview, we won't repeat the Vault documentation. Instead, we recommend that you study the Vault documentation and consider getting certified on the Vault product.

Multi-tenancy in MAAS

Likewise, you want to grant fine-grained access-controls to different users, based on assigned roles. Working in concert with RBAC and Candid, MAAS can restrict user access and actions based on four roles:

MAAS controls access with the help of RBAC (Role-Based Access Control), Candid (Canonical Identity Manager), and an identity service of your choice, such as SSO (Single Sign-On). You can design and deploy a controlled MAAS environment using MAAS/RBAC.

Resource pools group machines. Each machine is assigned to exactly one resource pool. If you control access to resource pools, and you assign roles properly, you control user access.

Note that just using resource pools to hide machines is a flawed access control approach, known as "security by obscurity." What users don't know will hurt you when the users figure it out -- usually entirely by accident, while trying to do the right thing.

Consequently, there must also be some means of active authorisation that allows access to a resource pool. That authorisation must be based on user identity. There must be some way of controlling what the user can do with that resource pool. In the parlance of standard security model, "what the user can do" would be called "privilege", but for the purposes of MAAS, we simply call them "permissions."

About identity services

MAAS/RBAC will interface with many identity services, using Candid as a mediator. The choice of identity service is up to you. As an example, let's take a closer look at Ubuntu Single Sign-On (SSO).

SSO permits users to log in once to access many network services. SSO centralises authentication (via Kerberos), account management (via LDAP), resource-sharing (via pam_mount), and limited authorisation through group memberships in LDAP, coupled with file permissions.

RBAC (Role-based access control) does not authenticate users or verify their identity; that function is assigned to the identity service you choose. RBAC does receive an identity token or "macaroon" (via Candid) that RBAC uses to assign user roles. MAAS uses these roles, in turn, to control user access and actions.

How Candid fits into the picture

Direct authentication involves a user entering something uncommon or unique in response to a challenge, in order to gain access. "Something uncommon" means "something you know" or "something you have, like a password or a hardware key. "Something unique" means "something you are", like a fingerprint. Authentication can be automated with private/public key exchanges, protected with a password on the first exchange. Adding another access point (another trusted client) usually means providing a public key, setting a password, or registering some biometric data. Direct authentication works well when there are a limited number of clients and not a lot of user turnover.

Increase users and services that need to authenticate, and direct authentication requires more effort: generating access requests; validating requests; setting up authentication; and then managing access as users move around the organisation. Candid, the Canonical identity service, was designed to meet this need. Candid acts as an authentication gateway that connects a service (e.g., RBAC) to your chosen identity service.

Candid manages authenticated users via special access tokens (macaroons) that confirm user identity. Unlike standard access tokens, macaroons

can be verified independently, in a standard way, reducing network traffic and repeated queries. Traditional access tokens must be short-lived; macaroons are valid for much longer and more easily refreshed. Macaroons can also be bound to TLS certificates, and used by multiple clients and services with no loss of security.

Candid can do the following things:

Candid can use certificates and agents, if desired. You specify the identity provider by URL when instantiating the program.

When a user logs into an RBAC-enabled MAAS server, that login is redirected to RBAC. RBAC authenticates via Candid, which consults the chosen identity server. If the user is authenticated, Candid constructs a macaroon and passes it to RBAC -- and on to MAAS. This macaroon serves as the user's authentication token until it expires.

To find out more about Candid and how to use it, consult the github README or get in touch with your sales representative.

About RBAC

RBAC uses a database to associate a given role with a properly-authenticated user identity. With RBAC, permissions are associated with roles, not individual users. Within a given resource pool, the role assigned to a properly authenticated user controls user access and actions. MAAS becomes an RBAC service, while each resource pool becomes a scope. RBAC/MAAS also recognises scopes that are not tied to machines, including:

RBAC also helps MAAS control access to these "non-machine resources".

Any given user may be an operator for one resource pool, a user for another, and an auditor for still another, all with no ability to change system settings or manipulate images. RBAC permits such arrangements.

The MAAS/RBAC permissions model

Here is a thumbnail sketch of the permissions model:

Relationships among roles, resource pools, and users are maintained by RBAC as a source of truth. MAAS mediates access to resource pools, based on user roles, using information obtained from RBAC.

The MAAS/RBAC security architecture

The following diagram will give you a graphical view of how MAAS, RBAC, Candid, and an identity provider work together to control access to MAAS resources:

Here is a step-by-step walk-through of the MAAS/RBAC relationship:

Note that RBAC does not adjudicate individual permissions against resource pools. RBAC sends MAAS the combination of users, roles, and related resource pools to MAAS when requested. The MAAS code has a built-in understanding of the four roles (user, administrator, operator, and auditor) and what those roles can and cannot do with a given item.

How the four MAAS RBAC roles protect MAAS resources

MAAS RBAC roles prevent users from seeing or interacting with machines in non-permitted resource pools. Even if a user knows the name or system ID of a machine in a non-permitted resource pool, that user can't access it. Removing non-permitted machines from view prevents confusion.

MAAS makes no assumptions about how these roles might be used in the day-to-day operation of your MAAS instance.