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. Section 3.1, "Two-way TLS authentication in the Load-balancing service" Section 3.2, "Certificate lifecycles for the Load-balancing service" Section 3.3, "Configuring Load-balancing service certificates and keys" 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. Note 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 Section 3.3, "Configuring Load-balancing service certificates and keys" 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 Section 3.3, "Configuring Load-balancing service certificates and keys" 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. Important 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. Note 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: Create a YAML custom environment file. Example 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. Important You must set OctaviaGenerateCerts to false. Example Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file. Important The order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence. Example Additional resources Section 4.3, "Changing Load-balancing service default settings" Environment files in the Director Installation and Usage guide Including environment files in overcloud creation in the Director Installation and Usage guide

Commands:
source ~/stackrc
vi /home/stack/templates/my-octavia-environment.yaml
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]
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