Ah, are you saying that "shadow tenant" is not possible in standard
Openstack? (I did wonder if that was the case).
I like your idea about putting the trove guest config on tmpfs, that
could be the answer! (I guess as the standard images have no swap either
that stops another line of attack to get the configuration details).
regards
Mark
On 06/02/17 14:53, Sergio Morales Acuña wrote:
Thanks you all for your answers.
I'm working with Trove on a Public Cloud and we have a separate
RabbitMQ Cluster just for Trove.
I now understand that the use of a "shadow tenant" it's a very
specific implementation of Trove.
Today, the only security concern we have is the rabbitmq password in
the trove-gustagent.conf file. We are also testing the use of two
ramdisks (tmpfs) for the /etc/trove/conf.d files and the "cloud-init"
files inside the guest image to minimize the risk.
Cheer and once again thank you for your answers.
El dom., 5 feb. 2017 a las 19:22, Mark Kirkwood
(<[email protected]
<mailto:[email protected]>>) escribió:
Hi Sergio,
With respect to the rabbit security - you can (and probably
should) use
a different rabbit server for the trove message queue i.e not your
openstack rabbit. I *think* this is mentioned in the trove deployment
docs these days (it didn't used to be), and it is easy to miss
wherever
it is mentioned! However this by itself is not enough really - as your
trove rabbit can be dos'd/hacked to cause mayhem to all running trove
instances.
The shadow tenant seems like the plan. However you are absolutely
correct - how to actually set it up is...err not that well documented.
I've made a comment on one of the various blogs to that effect. I'm
hoping it will spur one of the experts to show us in detail how it is
done :-)
regards
Mark
On 04/02/17 05:42, Sergio Morales Acuña wrote:
> Hi.
>
> I'm looking for information about the "Trove Shadow Tenant" feature.
>
> There some blogs talking about this but I can't find any information
> about the configuration.
>
> I have a working implementation of Trove but the instance is created
> in the same project as the user requesting the database. This is a
> problem for me because the user can create a snapshot of the
instance
> and capture the RabbitMQ password.
>
> I tried a non-admin credentials for nova_proxy_*, but the
instance is
> still been created in the user project. I'm using the branch
> stable/newton.
>
> Cheers.
>
>
> _______________________________________________
> Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : [email protected]
<mailto:[email protected]>
> Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
