Comment 3 for bug 1445295

I'm examining this using a devstack setup, however I think the issues you raise apply equally well to any trove installation.

So - image access: the way this appears to work is that the guest image *must* be available to the tenant/user creating the trove instance (I experimented with making it available to - say - admin only and instances cannot be created at all then). This automatically means the tenant can (with some playing about) read the rabbit password.

Even *if* we could protect the image, then I think the tenant/user can simply look at the running trove instance via the *cinder* api and snapshot the volume and mount it somewhere else to examine at leasure (I have not tried this yet, but see no reason why it would not work)...

 I notice Nikhil has just suggested using a separate rabbit server for trove in the email thread, so I guess this might mean a separate rabbit server (or perhaps rabbit users) per tenant? This seems to lead to an endless proliferation of... rabbits (ironic eh), and clearly (to me) seems simply wrong.