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.

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

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.

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

  1. Log in to the undercloud host as the stack user.

  2. Source the undercloud credentials file: 

    $ source ~/stackrc

  3. Create a YAML custom environment file.

    Example

    $ vi /home/stack/templates/my-octavia-environment.yaml

  4. 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

      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]

  5. 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

    $ 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