Configure OpenStack APIs to use X.509 certificates for MySQL

Configure OpenStack APIs to use X.509 certificates for MySQL

MCP enables you to enhance the security of your OpenStack cloud by requiring X.509 certificates for authentication. Configuring OpenStack APIs to use X.509 certificates for communicating with the MySQL database provides greater identity assurance of OpenStack clients making the connection to the database and ensures that the communications are encrypted.

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

The OpenStack services that support X.509 certificates include: Aodh, Barbican, Cinder, Designate, Glance, Gnocchi, Heat, Ironic, Keystone, Manila Neutron, Nova, and Panko.

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:

  1. Configure the X.509 support on the Galera side:

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

      system.galera.server.database.x509.<openstack_service_name>
      
    2. Apply the changes by running the galera state:

      Note

      On an existing environment, the already existing database users and their privileges will not be replaced automatically. If you want to replace the existing users, you need to remove them manually before applying the galera state.

      salt -C 'I@galera:master' state.sls galera
      
  2. Configure the X.509 support on the service side:

    1. Configure all OpenStack APIs that support X.509 to use X.509 certificates by setting openstack_mysql_x509_enabled: True on the cluster level of your deployment model:

      parameters:
        _param:
          openstack_mysql_x509_enabled: True
      
    2. Define the certificates:

      1. Generate certificates automatically using Salt:

        salt '*' state.sls salt.minion
        
      2. 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:
            database:
              x509:
                cacert: (certificate content)
                cert: (certificate content)
                key: (certificate content)
        

        OpenStack service

        Define custom certificates in pillar

        Apply the change

        Aodh

        aodh:
         server:
           database:
             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:
            database:
              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:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
          volume:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
        
        salt -C 'I@cinder:controller' state.sls cinder
        

        Designate

        designate:
          server:
            database:
              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:
           database:
              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
        

        Gnocchi

        gnocchi:
          common:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
        
        salt -C 'I@gnocchi:server' state.sls gnocchi.server
        

        Heat

        heat:
          server:
            database:
              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:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
          conductor:
            database:
              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:
            database:
              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:
           database:
             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:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
        
        salt -C 'I@neutron:server' state.sls neutron.server
        

        Nova

        nova:
          controller:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
        
        salt -C 'I@nova:controller' state.sls nova.controller
        

        Panko

        panko:
          server:
            database:
              x509:
                ca_cert: <path/to/cert/file>
                cert_file: <path/to/cert/file>
                key_file: <path/to/cert/file>
        
        salt -C 'I@panko:server' state.sls panko
        
  3. To verify that a particular client is able to authorize with X.509, verify the output of the mysql --user-name=<component_name> on any controller node. For example:

    mysql --user-name=nova --host=10.11.0.50 --password=<password> --silent \
      --ssl-ca=/etc/nova/ssl/mysql/ca-cert.pem \
      --ssl-cert=/etc/nova/ssl/mysql/client-cert.pem \
      --ssl-key=/etc/nova/ssl/mysql/client-key.pem