TLS Termination in MaaS 3.2

Users
,
1

Have been using MaaS for a few years now and really appreciate the effort that everyone has contributed to help make bare metal deployments easy and repeatable.

Something appears to have changed in how TLS termination works between MaaS 3.0 and MaaS 3.2. We’ve probably just missed something in the documentation, looking for someone who can point us in the right direction.

Per the docs we had been using an nginx reverse proxy to handle TLS termination

server {
listen 443 ssl;
 server_name _;
ssl_certificate /etc/ssl/certs/maas01.example.com.pem;
ssl_certificate_key /etc/ssl/private/maas01.example.com.key;
 location / {
  proxy_pass http://localhost:5240;
  include /etc/nginx/proxy_params;
}
 location /MAAS/ws {
  proxy_pass http://localhost:5240/MAAS/ws;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "Upgrade";
}
}

What we see after upgrading is that when we browse to https://maas01.example.com we are redirected to http://maas01.example.com:5420/MAAS/r/

This redirect appears to be coming from
/var/snap/maas/current/http/regiond.nginx.conf
Specifically lines 20-26

    location = / {
        return 301 /MAAS/r/;
    }

    location ~ ^/MAAS/?$ {
        return 301 /MAAS/r/;
    }

If users manually browse to https://maas01.example.com/MAAS/r/ TLS termination works as expected.

The newer documentation seems to recommend that HAProxy is used for TLS termination rather than Apache2 or Nginx. We did confirm that we see the exact same behavior if we use HAProxy instead of nginx

frontend maas
    bind *:443 ssl crt /etc/ssl/private/maas01.example.com.pem
    reqadd X-Forwarded-Proto:\ https
    retries 3
    option redispatch
    default_backend maas
backend maas
    timeout server 90s
    balance source
    hash-type consistent
    server localhost localhost:5240 check

What is the recommended method for TLS termination to ensure that requests to https://maas01.example.com get redirected to https://maas01.example.com/MAAS/r/ or appropriate path?

2

Hi @sjtanner.

Could you please provide the output of curl -L --head <MAAS URL> so that we could understand where exactly that redirect to HTTP happens? Thanks in advance!

3

@igor-brovtsin,
Here you go:

curl -L --head https://maas01.example.com
HTTP/1.1 301 Moved Permanently
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 08 Dec 2022 17:59:15 GMT
Content-Type: text/html
Content-Length: 178
Location: http://maas01.example.com:5240/MAAS/r/

HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Thu, 08 Dec 2022 17:59:15 GMT
Content-Type: text/html
Content-Length: 2767
Last-Modified: Wed, 21 Sep 2022 18:26:56 GMT
Connection: keep-alive
ETag: "632b5770-acf"
Accept-Ranges: bytes
4

Thank you!

Could you please also describe your environment? Specifically,

  • do you use snap or deb install of MAAS? (I suppose snap since you refer to files in /var/snap dir, but still we need to clarify that)
  • do you have your own reverse-proxy before the MAAS nginx? If so, could you please also share its configuration?

Also, MAAS 3.2 introduced native TLS support requiring no additional reverse-proxies, have you tried/considered using that?

5

@igor-brovtsin,

We are using the snap installation, although we did migrate from deb to snap somewhere around maas 2.8.

Yes we are using a reverse proxy in front of the MaaS nginx. Configuration is here:

This reverse proxy has been in place since MaaS 2.3 without any issues. It was only after the update from 3.0.x to 3.2.x that we encountered this issue.
We are aware of the new native support for TLS, which we plan on implementing native TLS when we move to an HA deployment. In our testing without native TLS enabled we encountered the same behavior using HA proxy as documented here https://maas.io/docs/how-to-secure-maas#heading--install-ha-proxy.

6

Hi @sjtanner
It seems to be a known bug

7

@troyanov,
Okay Thanks!