[Trove] State of the Trove service tenant deployment model

Zane Bitter zbitter at redhat.com
Tue Jan 22 06:29:25 UTC 2019

On 22/01/19 12:13 PM, Michael Richardson wrote:
> Hi Andy,
> On Tue, 22 Jan 2019 09:43:17 +1100 Andy Botting <andy at andybotting.com> wrote:
> <snip for clarity>
>> We've had it running in production on the Nectar cloud for the last 12
>> months. The work I did made it upstream, so you should be right to go from
>> at least Queens.
>> You'll just need to set something like this in your Trove config:
>> nova_proxy_admin_user = trove
>> nova_proxy_admin_pass = <pass>
>> nova_proxy_admin_tenant_name = trove
>> remote_nova_client =
>> trove.common.single_tenant_remote.nova_client_trove_admin
>> remote_cinder_client =
>> trove.common.single_tenant_remote.cinder_client_trove_admin
>> remote_neutron_client =
>> trove.common.single_tenant_remote.neutron_client_trove_admin
>> cheers,
>> Andy
> Superb -- great to hear!
> Would it be fair to say that the old Rabbit message bus security issue (shared credentials that could be extracted from backups) is no longer an issue?  (Apologies if this is long gone -- from an initial foray into the code it was hard to tell).

Last time I heard (which was probably mid-2017), the Trove team had 
implemented encryption for messages on the RabbitMQ bus. IIUC each DB 
being managed had its own encryption keys, so that would theoretically 
prevent both snooping and spoofing of messages. That's the good news.

The bad news is that AFAIK it's still using a shared RabbitMQ bus, so 
attacks like denial of service are still possible if you can extract the 
shared credentials from the VM. Not sure about replay attacks; I haven't 
actually investigated the implementation.


More information about the openstack-discuss mailing list