Chapter 4. Enabling TLS on a deployed RHOSO environment

Procedure

1. Open your OpenStackControlPlane custom resource (CR) file, openstack_control_plane.yaml, on your workstation.

2. Add the following spec.tls configuration, if not already present:

   spec:
     tls:
       ingress:
         ca:
           duration: 87600h0m0s
         cert:
           duration: 43800h0m0s
         enabled: true
       podLevel:
         enabled: true
         internal:
           ca:
             duration: 87600h0m0s
           cert:
             duration: 43800h0m0s
         libvirt:
           ca:
             duration: 87600h0m0s
           cert:
             duration: 43800h0m0s
         ovn:
           ca:
             duration: 87600h0m0s
           cert:
             duration: 43800h0m0s

   • If the tls configuration is already present in the CR file, then ensure that the podLevel is enabled.

3. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

4. The rabbitmq pods cannot change the TLS configuration on an operating environment, therefore you must delete the existing rabbitmq pods to update the control plane with the new rabbitmq pods that have TLS enabled:

   $ oc delete pod -n openstack -l app.kubernetes.io/component=rabbitmq

5. Wait for the control plane to be ready:

   $ oc wait openstackcontrolplane -n openstack --for=condition=Ready --timeout=400s -l core.openstack.org/openstackcontrolplane

   While waiting for the control plane to be ready, new workloads cannot be created and existing workloads cannot be managed with the OpenStack API. The nova-compute service on the data plane nodes cannot connect to the cell1 rabbitmq and reports as down:

   $ oc rsh openstackclient
   $ openstack compute service list -c Binary -c Host -c Status -c State
   +----------------+-------------------------------------+---------+-------+
   | Binary         | Host                                | Status  | State |
   +----------------+-------------------------------------+---------+-------+
   | nova-conductor | nova-cell0-conductor-0              | enabled | up    |
   | nova-scheduler | nova-scheduler-0                    | enabled | up    |
   | nova-conductor | nova-cell1-conductor-0              | enabled | up    |
   | nova-compute   | edpm-compute-0.ctlplane.example.com | enabled | down  |
   | nova-compute   | edpm-compute-1.ctlplane.example.com | enabled | down  |
   +----------------+-------------------------------------+---------+-------+

   The OVN controller and the OVN metadata agent cannot connect to the southbound database:

   $ openstack network agent list -c 'Agent Type' -c Host -c Alive -c State
   +------------------------------+-------------------------------------+-------+-------+
   | Agent Type                   | Host                                | Alive | State |
   +------------------------------+-------------------------------------+-------+-------+
   | OVN Controller Gateway agent | crc                                 | :-)   | UP    |
   | OVN Controller agent         | edpm-compute-1.ctlplane.example.com | XXX   | UP    |
   | OVN Metadata agent           | edpm-compute-1.ctlplane.example.com | XXX   | UP    |
   | OVN Controller agent         | edpm-compute-0.ctlplane.example.com | XXX   | UP    |
   | OVN Metadata agent           | edpm-compute-0.ctlplane.example.com | XXX   | UP    |
   +------------------------------+-------------------------------------+-------+-------+

   Note

   The existing workload is not impacted if workload traffic is not routed through the control plane.

6. Open the OpenStackDataPlaneNodeSet CR file for each node on the data plane, and enable TLS in each:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: <node_set_name>
     namespace: openstack
   spec:
     tlsEnabled: true

   where:

   <node_set_name>

   Specifies the name of the OpenStackDataPlaneNodeSet CR that the node belongs to.

7. Save the updated OpenStackDataPlaneNodeSet CR files and apply the updates:

   $ oc apply -f openstack_data_plane.yaml -n openstack

8. Check that TLS is enabled on each node set:

   $ oc get openstackdataplanenodeset <node_set_name> -n openstack -o json | jq .items[0].spec.tlsEnabled
   true

9. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: <node_set_deployment_name>

   where:

   <node_set_deployment_name>

   Specifies the name of the OpenStackDataPlaneDeployment CR. The name must be unique, must consist of lower case alphanumeric characters, - (hyphen) or . (period), and must start and end with an alphanumeric character.

   Tip

   Give the OpenStackDataPlaneDeployment CR file a descriptive name that indicates the purpose of the modified node set.

10. Add the OpenStackDataPlaneNodeSet CRs that you modified to enable TLS:

    spec:
      nodeSets:
        - <node_set_name>

    • Provide the required <node_set_name> for each node on the data plane.
11. Save the OpenStackDataPlaneDeployment CR deployment file.

12. Deploy the modified OpenStackDataPlaneNodeSet CRs:

    $ oc create -f openstack_data_plane_deploy.yaml -n openstack

    You can view the Ansible logs while the deployment executes:

    $ oc get pod -l app=openstackansibleee -n openstack -w
    $ oc logs -l app=openstackansibleee -f --max-log-requests 10 -n openstack

    If the oc logs command returns an error similar to the following error, increase the --max-log-requests value:

    error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit

13. Verify that the modified OpenStackDataPlaneNodeSet CRs are deployed:

    $ oc get openstackdataplanedeployment -n openstack
    NAME             	STATUS   MESSAGE
    openstack-data-plane   True     Setup Complete
    
    
    $ oc get openstackdataplanenodeset -n openstack
    NAME             	STATUS   MESSAGE
    openstack-data-plane   True     NodeSet Ready

    For information about the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

    If the status indicates that the data plane has not been deployed, then troubleshoot the deployment. For information, see Troubleshooting the data plane creation and deployment in the Deploying Red Hat OpenStack Services on OpenShift guide.

14. Verify that the nova-compute service is connected again to TLS rabbitmq:

    $ oc rsh openstackclient
    $ openstack compute service list -c Binary -c Host -c Status -c State
    +----------------+-------------------------------------+---------+-------+
    | Binary         | Host                                | Status  | State |
    +----------------+-------------------------------------+---------+-------+
    | nova-conductor | nova-cell0-conductor-0              | enabled | up    |
    | nova-scheduler | nova-scheduler-0                    | enabled | up    |
    | nova-conductor | nova-cell1-conductor-0              | enabled | up    |
    | nova-compute   | edpm-compute-0.ctlplane.example.com | enabled | up    |
    | nova-compute   | edpm-compute-1.ctlplane.example.com | enabled | up    |
    +----------------+-------------------------------------+---------+-------+

15. Verify that the OVN agents are running again:

    $ openstack network agent list -c 'Agent Type' -c Host -c Alive -c State
    +------------------------------+-------------------------------------+-------+-------+
    | Agent Type                   | Host                                | Alive | State |
    +------------------------------+-------------------------------------+-------+-------+
    | OVN Controller Gateway agent | crc                                 | :-)   | UP    |
    | OVN Controller agent         | edpm-compute-1.ctlplane.example.com | :-)   | UP    |
    | OVN Metadata agent           | edpm-compute-1.ctlplane.example.com | :-)   | UP    |
    | OVN Controller agent         | edpm-compute-0.ctlplane.example.com | :-)   | UP    |
    | OVN Metadata agent           | edpm-compute-0.ctlplane.example.com | :-)   | UP    |
    +------------------------------+-------------------------------------+-------+-------+

Procedure

1. Open your OpenStackControlPlane custom resource (CR) file, openstack_control_plane.yaml, on your workstation.

2. Add the following spec.tls configuration, if not already present:

   spec:
     tls:
       ingress:
         enabled: false
       podLevel:
         enabled: false

3. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml

4. Open the OpenStackDataPlaneNodeSet CR file for each node on the data plane, and disable TLS by setting spec.tlsEnabled to false:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: <node_set_name>
     namespace: openstack
   spec:
     tlsEnabled: false

   where:

   <node_set_name>

   Specifies the name of the OpenStackDataPlaneNodeSet CR that the node belongs to.

5. Save the updated OpenStackDataPlaneNodeSet CR files and apply the updates:

   $ oc apply -f openstack_data_plane.yaml

6. Verify that TLS is disabled on every node set:

   $ oc get openstackdataplanenodeset <node_set_name> -n openstack -o json | jq .items[0].spec.tlsEnabled