[Openstack-operators] Trove Shadow Tenant

Sergio Morales Acuña semoac at gmail.com
Tue Feb 7 14:32:45 UTC 2017


Dear Amrith,


Thank you for responding this thread.

I don't know if we have a "vector" here but the deal is this: We are
offering a Public Cloud and for us in unacceptable that users can have
access to any password of any of the component of any service.

Now, in this case, the user can take a snapshot of the instance running the
trove guest-agent, create a volume, attach the volume to another VM and
capture the rabbitMQ password.

I'm not expert on RabbitMQ and I don't know if with this  a user can create
a python script to continuously take the messages and send them to
/dev/null or something like this. Because I'm not expert on RabbitMQ, I'm
not interest on having to worry about things like this. The idea of a user
having access to any password is just unacceptable ([1]).

About tmpfs, we setup the fstab of the guest image with this:

tmpfs /etc/trove/conf.d/ tmpfs defaults,size=1m 0 0
tmpfs /var/lib/cloud/ tmpfs defaults,size=1m 0 0

Now if a user take a snapshot of the instance, they will not have access to
any configuration file, because this paths will be writen on RAM. We are
still doing some test but until now is working fine.

Cheers.

[1]: https://www.youtube.com/watch?v=07So_lJQyqw

El lun., 6 feb. 2017 a las 20:29, Amrith Kumar (<amrith.kumar at gmail.com>)
escribió:

> Sergio,
>
> Sounds like I may have been replying only to you, not the list.
>
> A couple of things to recap from the emails I’d sent you.
>
> 1. From the description of what you are doing, I’m not sure that single
> tenant remote (or shadow tenant) would be my first choice.
>
> 2. If you go the route of tmpfs, I suspect that some things in Trove won’t
> work. At the very least, I think resize instance is one of those things. I
> don’t follow the logic behind the tmpfs choice but would love to understand
> more about that. I see a reference in the mail thread below that it may
> address some attack vector but I'm not certain what that vector is.
>
> 3. The single tenant remote code broke recently and the focus was on
> getting the main code paths fixed (this is in the past week or so), fixing
> single tenant remote is on my list of things to do. I think you found Matt
> Reidmann's bug on this as well (I've duped that to the bug you entered).
>
> Documentation of single-tenant-remote and shadow tenant can certainly do
> with some improvement, seems like a good thing to do once the code gets
> fixed up.
>
> -amrith
>
> ---
>
> From: Sergio Morales Acuña [mailto:semoac at gmail.com]
> Sent: Tuesday, February 7, 2017 1:43 AM
> To: Sam Morrison <sorrison at gmail.com>
> Cc: openstack-operators at lists.openstack.org
> Subject: Re: [Openstack-operators] Trove Shadow Tenant
>
> I'm going to use tmpfs.
>
> I found many errors when using this feature (
> https://bugs.launchpad.net/trove/+bug/1662300).
>
> Thank you all for your time.
>
> El dom., 5 feb. 2017 a las 23:50, Sam Morrison (<mailto:sorrison at gmail.com>)
> escribió:
> Hi Sergio,
>
> I’m very interested in this feature too, it might be worth asking in the
> openstack-trove IRC channel or on the openstack-dev mailing list (adding a
> [trove] in the subject should get their attention) to get some answers to
> this question.
>
> Cheers,
> Sam
>
>
> > On 4 Feb 2017, at 1:34 am, Sergio Morales Acuña <mailto:semoac at gmail.com>
> 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.
> >
> > Cheers.
> > _______________________________________________
> > OpenStack-operators mailing list
> > mailto:OpenStack-operators at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170207/300aeb0a/attachment.html>


More information about the OpenStack-operators mailing list