Security¶

MAAS enforces strict access control and secure secret management to protect system integrity.

TLS termination¶

SSL should be replaced with Transport Layer Security (TLS). A TLS-terminated load balancer routes incoming Web UI and API requests across region controllers, reducing workload and latency. Encryption and decryption occur at the edge of the network; in this case, right at the load balancer. TLS better ensures privacy and data integrity through symmetric cryptography and message authentication codes.

Certificate expiration¶

When the specified number of days remain until certificate expiration (as defined in the notification reminder), all administrators will see the certificate expiration notification. This notification enumerates the number of days until certificate expiration. It can be dismissed, but once dismissed, it won’t appear again.

A certificate expiration check runs every twelve hours. When the certificate has expired, the notification will change to “certificate has expired”.

Note that MAAS does not auto-renew certificates.

Security hardening¶

MAAS security hardening enforces STIG/CIS transport-security controls on the region controller. Hardening is a posture, not a gate: MAAS validates its prerequisites at startup but never refuses to start over an unmet one. A single missing setting on a compliance host is a visible, fixable signal rather than a boot failure that takes a controller offline.

Activation¶

Hardening is controlled by the hardening_enabled setting. The default value, auto, activates hardening when the host is in FIPS mode. An administrator can also activate hardening explicitly on any host with maas config-hardening enable, or disable it with maas config-hardening disable. On a FIPS host, hardening cannot be turned off. For the relationship between FIPS mode and MAAS, see FIPS mode.

Violations as notifications¶

When hardening is active, startup validation checks the public-API TLS certificate, DH parameters, service bind addresses, and the PostgreSQL SSL mode. Each unmet prerequisite is posted as an admin-targeted, non-dismissable error notification keyed by a stable identifier — the same mechanism the certificate-expiration check uses. Because the notifications are non-dismissable, a compliance violation cannot be hidden; it can only be resolved. When the underlying setting is corrected, the notification clears on the next startup. Administrators can also run maas config-hardening validate for the same result on demand, which is useful as audit evidence.

This differs from the certificate-expiration notification, which is dismissable — an expiring certificate is a reminder, whereas an active hardening violation is a compliance finding that must be fixed rather than acknowledged.

Region and rack scope¶

The notification model lives on the region controller: violations found there are posted as Notification rows, visible in the web UI and API. A rack controller applies its own hardening controls locally (its own bind addresses in rackd.conf) but has no region-facing channel for posting notifications, so rack-local configuration violations are not surfaced cross-host or recorded in the region database. To audit a rack controller’s own hardening posture, run maas-rack config-hardening validate on that rack.

See Security hardening reference for the parameters, stores, and violation codes, and Activate MAAS hardening for setup steps.

Shared secrets¶

When you add a new rack or region controller, MAAS asks for a shared secret it will use to communicate with the rest of MAAS. This secret is also exposed in the web UI when you click the ‘Add rack controller’ button on the Controllers page. MAAS automatically generates this secret when your first region controller installed, and stores the secret in a plain text file. This file is automatically protected with the correct permissions, so there is no need for any action on your part.

As a MAAS administrator, it’s crucial to avoid storing secrets associated with your MAAS instance in the database. This includes secrets like the OMAPI key and the RPC secret.

HashiCorp Vault¶

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

Vault employs identity for securing secrets and encryption keys. Its core component is the kv secrets engine, which utilizes key-value pairs to store secrets within an encrypted storage managed by Vault. You can explore more about secrets engines if you’re interested.

Vault safeguards the secrets engine using a barrier view, creating a folder with a randomly-generated UUID as the absolute root directory for that engine. This prevents the engine from accessing secrets outside its UUID folder.

Vault is compatible with MAAS version 3.3 and above. Please upgrade if you’re using an older version of MAAS and want to use Vault.

Learn more about Hashicorp Vault.

PostgreSQL security¶

PostgreSQL contains secrets, and should be encrypted for maximum protection. You should consider full disk encryption. Also recommended is TLS encryption between MAAS and PostgreSQL.

Strong passwords¶

You should pick good passwords and store them securely (e.g. in a KeePassX password database). Perform user administration only via the web UI. Only share the maas and root user passwords with administrators.

Valid permissions¶

MAAS configuration files should be set to have permission 640: readable by logins belonging to the maas group and writeable only by the root user. Currently, the regiond.conf file contains the login credentials for the PostgreSQL database used by MAAS to keep track of all machines, networks, and configuration.

Pkg Fmt	chmod 640 on files…	Final Perms
Snap	`/var/snap/maas/current/regiond.conf`	`-rw-r-----`
	`/var/snap/maas/current/rackd.conf`	`-rw-r-----`
Packages	`/etc/maas/rackd.conf/regiond.conf`	`-rw-r-----`
	`/etc/maas/rackd.conf/rackd.conf`	`-rw-r-----`

Snap security¶

Snaps are fully confined or ‘sandboxed,’ offering inherent security for the enclosed application. For more detailed information, see this snap blog.

Role-Based Access Control (RBAC)¶

MAAS assigns access based on roles:

Administrator – Full access to all settings and machines.
Operator – Admin privileges within assigned resource pools.
User – Access to unallocated machines but no settings.
Auditor – Read-only access to assigned resource pools.

RBAC, Candid, and an identity provider (e.g., SSO) manage authentication.

Resource pools & permissions¶

Each machine belongs to one resource pool. Users access machines based on roles. Hiding machines is not security—proper authorization is required.

Identity services & Candid¶

MAAS supports multiple identity services via Candid, Canonical’s authentication gateway. Candid issues macaroons—tokens that verify users without repeated authentication requests.

RBAC & MAAS integration¶

RBAC associates roles with authenticated identities, not individual users. It governs:

Machines in resource pools
DNS, availability zones, images, and settings

A user can have different roles across pools—e.g., Operator in one, Auditor in another.

RBAC workflow¶

MAAS syncs resource pools with RBAC.
User login is redirected to RBAC.
RBAC authenticates via Candid.
Candid validates the user via an identity provider (e.g., SSO).
If authenticated, Candid issues a macaroon.
RBAC sends the macaroon and role details to MAAS.
MAAS grants access based on role-resource pairings.

RBAC does not check permissions per resource pool—MAAS enforces them based on roles.

RBAC roles summary¶

Role	Permissions
Administrator	Full access (all settings, machines, pools).
Operator	Admin privileges within assigned resource pools.
User	Can allocate machines but can’t change settings.
Auditor	Read-only access to permitted resource pools.

MAAS enforces role-based visibility. Users cannot access non-permitted machines, even if they know the system ID.

Security consulting¶

If you need help implementing MAAS security, please contact us. We will be happy to assist you in arranging security consulting appropriate to your needs.