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 and FIPS mode

MAAS can apply STIG- and CIS-aligned transport-security controls to its controllers. These controls activate automatically when a controller’s host is in FIPS mode, and you can also activate them on any other host. When a prerequisite is missing, MAAS keeps running and reports the problem as a non-dismissable notification for administrators.

For the concepts, see FIPS mode and security hardening. To set up a hardened controller, see Activate MAAS hardening.

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.

File	Permissions
/var/snap/maas/current/regiond.conf	-rw-r-----
/var/snap/maas/current/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.

Fine-grained authorization

MAAS 3.8 introduces a built-in relationship-based access control (ReBAC) system for fine-grained authorization. Access follows the chain user → group → entitlement → resource: users belong to groups, and groups are granted entitlements (permissions) on resources.

Entitlements are scoped either globally (the maas resource) or per resource pool (the pool resource). Resource pools are therefore the unit of access control: you can grant a group per-pool entitlements such as can_view_machines, can_deploy_machines, or can_edit_machines, restricting that group to just the machines in the pool. Global machine permissions cascade to every pool, while per-pool entitlements grant additional access to specific pools only.

MAAS enforces these entitlements on every request, so users cannot access machines they are not entitled to, even if they know the system ID. Hiding machines is not security—proper authorization is required.

For the full permission model, the list of available entitlements, and CLI examples, see User groups and entitlements.

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.