Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Chapter 1. Administering Database-as-a-Service

1.1. Install and Configure the Database-as-a-Service Controller

For detailed instructions on how to install the necessary packages and set up the environment on the DBaaS controller, see the Installation Reference.

1.2. Secure Database-as-a-Service

In earlier versions of Red Hat OpenStack Platform, the DBaaS guest agent ran with credentials to the RabbitMQ message bus which was used by the entire management controller for all its traffic. Consequently, the DBaaS instance could view all the data sent over the message bus, including sensitive data, which could allow the instance to misuse or attack other services sharing the bus. With Red Hat OpenStack Platform 8, DBaaS is placed into an isolated tenant which does not have access to the rest of the management controller. However, to further increase the security of your DBaaS, you can set up the DBaaS instance on a separate host and a separate RabbitMQ message bus. To do so, perform the following steps.

  1. On the management controller:

    1. Set the RabbitMQ user and password to custom values which will not be shared with the DBaaS tenant. For example, you can use the guest account and the / default virtual host with a changed password: 

      # rabbitmqctl change_password guest password

      The password will be changed in all the configuration files where services are set to connect to the message bus.

    2. Update the DBaaS database endpoint to make service catalog lookups use DBaaS on the separate host. First determine the current endpoint UUID, then delete it, and finally create a new endpoint with the IP address of the separate DBaaS host: 

      # keystone endpoint-list
# keystone endpoint-delete current_DBaaS_endpoint_uuid
# keystone endpoint-create --service trove --publicurl http://IP:8779/v1.0/\$\(tenant_id\)s --region RegionOne

  2. On the DBaaS controller:

    1. Point the authentication token filter in the WSGI configuration at the remote management controller host. Use the following options and values in the /etc/trove/api-paste.ini file, replacing IP with the IP address of the management controller host: 

      [filter:authtoken]
paste.filter_factory = keystonemiddleware.auth_token:filter_factory
service_protocol = http
service_host = IP
service_port = 5000
auth_host = IP
auth_port = 35357
auth_protocol = http
auth_uri = http://IP:35357/v2.0/
signing_dir = /tmp/keystone-signing-trove
admin_tenant_name = admin
admin_user = admin
admin_password = admin

    2. Add an admin user to ensure that the DBaaS guest agent has different secrets than those used in the management controller: 

      # rabbitmqctl add_user isolated isolated
# rabbitmqctl set_permissions isolated ".*" ".*" ".*"

    3. Configure the DBaaS control plane to connect to and authenticate against the local RabbitMQ instance by placing the following options and values into the /etc/trove/trove.conf file: 

      # AMQP Connection info
rabbit_userid=isolated
rabbit_password=isolated
rabbit_host=DBaaS_IP

# single instance tenant
nova_proxy_admin_user = user
nova_proxy_admin_pass = password
nova_proxy_admin_tenant_name = tenant
trove_auth_url = http://MGMT_IP:5000/v2.0
nova_compute_service_type = compute
cinder_service_type = volumev2
os_region_name = RegionOne
nova_compute_url = http://MGMT_IP:8774/v3

remote_nova_client = trove_ext.cloudos.remote.nova_client_trove_admin
remote_cinder_client = trove_ext.cloudos.remote.cinder_client_trove_admin
remote_neutron_client = trove_ext.cloudos.remote.neutron_client_trove_admin

  3. On the management controller, edit the /etc/trove/trove-guestagent.conf file as follows: 

    # AMQP Connection info
rabbit_userid=isolated
rabbit_password=isolated
rabbit_host=DBaaS_IP

# single tenant config
nova_proxy_admin_user = user
nova_proxy_admin_pass = password
nova_proxy_admin_tenant_name = tenant
trove_auth_url = http://MGMT_IP:5000/v2.0
swift_url = http://MGMT_IP:8080/v1/AUTH_

1.2.1. ACL Policies

Alternatively, you can improve the security by taking advantage of the ACL policies provided by RabbitMQ virtual hosts. In this case, you can assign separate users to each virtual host, including separate permissions. For example, you can define a virtual host called /isolated and assign the isolated user appropriate permissions for the virtual host. To do so, perform the following steps:

  1. Change the guest account password for the default / virtual host: 

    # rabbitmqctl change_password guest password

  2. Add the new user and virtual host and set the permissions appropriately: 

    # rabbitmqctl add_user isolated isolated
# rabbitmqctl add_vhost /isolated
# rabbitmqctl -p /isolated set_permissions isolated ".*" ".*" ".*"

  3. Edit the DBaaS configuration. There are two files to edit: /etc/trove/trove-guestmanager.conf, which is generated by packstack from puppet-trove and is to be injected into the guest instance, and /etc/trove/trove-conductor.conf, which configures the DBaaS control plane service for asynchronous status updates from the DBaaS instance. The RabbitMQ settings are identical for both files: 

    [oslo_messaging_rabbit]
rabbit_host=IP
rabbit_virtual_host=/isolated
rabbit_userid=isolated
rabbit_password=isolated
rabbit_port=5672
rabbit_ha_queues=False
rabbit_hosts=IP:5672
rabbit_use_ssl=False

The advantage of this approach is its simplicity in comparison with the scenario where separate hosts and message queues are used. This can be useful if provisioning is performed in an automated manner; for example, using Red Hat OpenStack Platform director.