TLS/HTTPS for load balancer

[franksc]

Load balancer component, as the public-facing interface for the service, should use TLS/HTTPS.

OpenStack Octavia load balancers support TLS termination at the load balancer (i.e. not passed through to pool members), which is ideal.

[franksc]

This works:

• use Let's Encrypt to generate a TLS certificate for whatever.austraits.cloud.edu.au
  • I used lego client with OpenStack Designate DNS provider
• stash TLS certificate and private key in OpenStack Barbican secrets
  • put cert in a 'certificate' secret, put key in a 'private_key' secret, then create a container secret referencing these (reference here)
• create Octavia load balancer listener using HTTPS with property default_tls_container_ref pointing to container secret for TLS stuff
• create DNS A record whatever.austraits.cloud.edu.au pointing to public IP for load balancer
• TLS connection to https://whatever.austraits.cloud.edu.au should work

However, automating the renewal and use of a Let's Encrypt certificate seems super fiddly because the value of an OpenStack secret can't be changed after it's created – so you can't just update a secret container over time with renewed/new TLS stuff and have the LB listener dynamically pick this up.

The components for automation would seem to be:

• something to interact with Let's Encrypt to periodically renew TLS certificate for domain name
• something to create OpenStack secrets containing new TLS stuff (and trash old secrets)
• something to update LB listener to point to new secret
• some 'wrangler' with visibility of which load balancer is fronted by which domain name

[franksc]

Marking this as 'wontfix' as implementing the described automation is out of current scope.

This should be revisited if:

• OpenStack implements some kind of integration with Let's Encrypt / ACME protocol and providers for automated creation and renewal of TLS certificates
• Austraits API service wants to add API key/token or similar authenticated access which sensibly requires a TLS/encrypted connection rather than vanilla HTTP