Configure OpenStack APIs to use X.509 certificates for RabbitMQ¶

MCP enables you to enhance the security of your OpenStack environment by requiring X.509 certificates for authentication. Configuring the OpenStack services to use X.509 certificates for communicating with the RabbitMQ server provides greater identity assurance of OpenStack clients making the connection to message_queue and ensures that the communications are encrypted.

When configuring X.509 for your MCP cloud, you enable the TLS support for the communications between RabbitMQ and the OpenStack services.

The OpenStack services that support X.509 certificates for communicating with the RabbitMQ server include Aodh, Barbican, Cinder, Designate, Glance, Heat, Ironic, Keystone, Manila, Neutron, and Nova.

To enable the X.509 and SSL support for communications between the OpenStack services and RabbitMQ:

1. Configure the X.509 support on the RabbitMQ server side:

   1. Include the following class to <cluster_name>/openstack/message_queue.yml of your deployment model:

      - system.rabbitmq.server.ssl
      

   2. Refresh the pillars:

      salt -C 'I@rabbitmq:server' saltutil.refresh_pillar
      

   3. Verify the pillars:

      Note

      X.509 remains disabled until you enable it on the cluster level as described further in this procedure.

      salt -C 'I@rabbitmq:server' pillar.get rabbitmq:server:x509
      

2. Configure the X.509 support on the service side:

   1. Configure all OpenStack services that support X.509 to use X.509 certificates for RabbitMQ by setting the following parameters on the cluster level of your deployment model in <cluster_name>/openstack/init.yml:

      parameters:
        _param:
          rabbitmq_ssl_enabled: True
          openstack_rabbitmq_x509_enabled: True
          openstack_rabbitmq_port: 5671
      

   2. Refresh the pillars:

      salt '*' saltutil.refresh_pillar
      

   3. Verify that the pillars for the OpenStack services are updated. For example, for the Nova controller:

      salt -C 'I@nova:controller' pillar.get nova:controller:message_queue:x509
      

      Example of system response:

      ctl03.example-cookiecutter-model.local:
        ----------
        ca_file:
            /etc/nova/ssl/rabbitmq/ca-cert.pem
        cert_file:
            /etc/nova/ssl/rabbitmq/client-cert.pem
        enabled:
            True
        key_file:
            /etc/nova/ssl/rabbitmq/client-key.pem
      ctl02.example-cookiecutter-model.local:
        ----------
        ca_file:
            /etc/nova/ssl/rabbitmq/ca-cert.pem
        cert_file:
            /etc/nova/ssl/rabbitmq/client-cert.pem
        enabled:
            True
        key_file:
            /etc/nova/ssl/rabbitmq/client-key.pem
      ctl01.example-cookiecutter-model.local:
        ----------
        ca_file:
            /etc/nova/ssl/rabbitmq/ca-cert.pem
        cert_file:
            /etc/nova/ssl/rabbitmq/client-cert.pem
        enabled:
            True
        key_file:
            /etc/nova/ssl/rabbitmq/client-key.pem
      

3. Generate certificates automatically using Salt:

   1. For the OpenStack services:

      salt '*' state.sls salt.minion
      

   2. For the RabbitMQ server:

      salt -C 'I@rabbitmq:server' state.sls salt.minion.cert
      

4. Verify that the RabbitmMQ cluster is healthy:

   salt -C 'I@rabbitmq:server' cmd.run 'rabbitmqctl cluster_status'
   

5. Apply the changes on the server side:

   salt -C 'I@rabbitmq:server' state.sls rabbitmq
   

6. Apply the changes for the OpenStack services by running the appropriate service states listed in the Apply the change column of the Definition of custom X.509 certificates for RabbitMQ table in the next step.

7. Optional. Define pre-created certificates for particular services in pillars as described in the table below.

   Note

   The table illustrates how to define pre-created certificates through paths. Though, you can include a certificate content to a pillar instead. For example, for the Aodh, use the following structure:

   aodh:
     server:
       message_queue:
         x509:
           cacert: <certificate_content>
           cert: <certificate_content>
           key: <certificate_content>
   

   Definition of custom X.509 certificates for RabbitMQ¶

   OpenStack service	Define custom certificates in pillar	Apply the change
   Aodh	aodh: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@aodh:server' state.sls aodh
   Barbican	barbican: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@barbican:server' state.sls barbican.server
   Cinder	cinder: controller: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file> volume: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@cinder:controller or I@cinder:volume' state.sls cinder
   Designate	designate: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@designate:server' state.sls designate
   Glance	glance: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@glance:server' state.sls glance.server
   Heat	heat: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@heat:server' state.sls heat
   Ironic	ironic: api: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file> conductor: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@ironic:api' state.sls ironic.api salt -C 'I@ironic:conductor' state.sls ironic.conductor
   Keystone	keystone: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@keystone:server' state.sls keystone.server
   Manila	manila: common: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file	salt -C 'I@manila:common' state.sls manila
   Neutron	neutron: server: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file> neutron: gateway: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@neutron:server or I@neutron:gateway or I@neutron:compute' state.sls neutron
   Nova	nova: controller: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file> nova: compute: message_queue: x509: ca_cert: <path/to/cert/file> cert_file: <path/to/cert/file> key_file: <path/to/cert/file>	salt -C 'I@nova:controller or I@nova:compute' state.sls nova

8. To verify that a particular client can authorize to RabbitMQ with an X.509 certificate, verify the output of the rabbitmqctl list_connections command on any RabbitMQ node. For example:

   salt msg01* cmd.run 'rabbitmqctl list_connections peer_host peer_port peer_cert_subject ssl'