Chapter 3. Securing the Load-balancing service
To secure communication between the various components of the Red Hat OpenStack Load-balancing service (octavia) uses TLS encryption protocol and public key cryptography.
3.1. Two-way TLS authentication in the Load-balancing service
The controller processes of the Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) communicate with Load-balancing service instances (amphorae) over a TLS connection. The Load-balancing service validates that both sides are trusted by using two-way TLS authentication.
This is a simplification of the full TLS handshake process. For more information about the TLS handshake process, see TLS 1.3 RFC 8446.
There are two phases involved in two-way TLS authentication. In Phase one a Controller process, such as the Load-balancing service worker process, connects to a Load-balancing service instance, and the instance presents its server certificate to the Controller. The Controller then validates the server certificate against the server Certificate Authority (CA) certificate stored on the Controller. If the presented certificate is validated against the server CA certificate, the connection proceeds to phase two.
In Phase two the Controller presents its client certificate to the Load-balancing service instance. The instance then validates the certificate against the client CA certificate stored inside the instance. If this certificate is successfully validated, the rest of the TLS handshake continues to establish the secure communication channel between the Controller and the Load-balancing service instance.
Additional resources
3.2. Certificate lifecycles for the Load-balancing service
The Red Hat OpenStack Platform (RHOSP) Load-balancing service (octavia) controller uses the server certificate authority certificates and keys to uniquely generate a certificate for each Load-balancing service instance (amphora).
The Load-balancing service housekeeping controller process automatically rotates these server certificates as they near their expiration date.
The Load-balancing service controller processes use the client certificates. The human operator who manages these TLS certificates usually grants a long expiration period because the certificates are used on the cloud control plane.
Additional resources
3.3. Configuring Load-balancing service certificates and keys
You can configure Red Hat OpenStack Platform (RHOSP) director to generate certificates and keys, or you can supply your own. Configure director to automatically create the required private certificate authorities and issue the necessary certificates. These certificates are for internal Load-balancing service (octavia) communication only and are not exposed to users.
RHOSP director generates certificates and keys and automatically renews them before they expire. If you use your own certificates, you must remember to renew them.
Switching from manually generated certificates to automatically generated certificates is not supported by RHOSP director. But you can enforce the re-creation of the certificates by deleting the existing certificates on the Controller nodes in the /var/lib/config-data/puppet-generated/octavia/etc/octavia/certs
directory and updating the overcloud.
If you must use your own certificates and keys, then complete the following steps:
Prerequisites
- Read and understand, "Changing Load-balancing service default settings." (See link in "Additional resources.")
Procedure
-
Log in to the undercloud host as the
stack
user. Source the undercloud credentials file:
$ source ~/stackrc
Create a YAML custom environment file.
Example
$ vi /home/stack/templates/my-octavia-environment.yaml
In the YAML environment file, add the following parameters with values appropriate for your site:
OctaviaCaCert
:The certificate for the CA that Octavia uses to generate certificates.
OctaviaCaKey
:The private CA key used to sign the generated certificates.
OctaviaCaKeyPassphrase
:The passphrase used with the private CA key above.
OctaviaClientCert
:The client certificate and un-encrypted key issued by the Octavia CA for the controllers.
OctaviaGenerateCerts
:The Boolean that instructs director to enable (true) or disable (false) automatic certificate and key generation.
ImportantYou must set
OctaviaGenerateCerts
to false.Example
parameter_defaults: OctaviaCaCert: | -----BEGIN CERTIFICATE----- MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQEBCwUAMFgxCzAJBgNV [snip] sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvp -----END CERTIFICATE----- OctaviaCaKey: | -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED [snip] -----END RSA PRIVATE KEY-----[ OctaviaClientCert: | -----BEGIN CERTIFICATE----- MIIDmjCCAoKgAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEP [snip] 270l5ILSnfejLxDH+vI= -----END CERTIFICATE----- -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDU771O8MTQV8RY [snip] KfrjE3UqTF+ZaaIQaz3yayXW -----END PRIVATE KEY----- OctaviaCaKeyPassphrase: b28c519a-5880-4e5e-89bf-c042fc75225d OctaviaGenerateCerts: false [rest of file snipped]
Run the
openstack overcloud deploy
command and include the core heat templates, environment files, and this new custom environment file.ImportantThe order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence.
Example
$ openstack overcloud deploy --templates \ -e <your_environment_files> \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/octavia.yaml \ -e /home/stack/templates/my-octavia-environment.yaml
Additional resources
- Section 4.3, “Changing Load-balancing service default settings”
- Environment files in the Advanced Overcloud Customization guide
- Including environment files in overcloud creation in the Advanced Overcloud Customization guide