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'