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.

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