Configure OpenStack APIs to use X.509 certificates for RabbitMQ

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.

Note

The procedures included in this section apply to new MCP OpenStack deployments only, unless specified otherwise.

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'