Open Stack

Hi Sergio,

I see where you are going with the tempfs. However, remember that when you
are using a service tenant, your cloud customers won't be able to snapshot
and download the volume. As a result, this attack vector is covered.

With a shadow tenant or service tenant, your real risk is someone
exploiting your DB, dropping on a shell and escalating their privileges so
that they can read the file where the guest-agent RabbitMQ password is
stored.

I had a discussion with Amrith at the summit and the conclusion was that
hardening the DB and adding SELinux / AppArmor as a second line of defence
is the best strategy right now.

@Amrith,

Please correct me if I'm wrong. As far as I remember Trove can be
configured using a service tenant or a shadow tenant.

With a service tenant, all DB instances go to a single Trove owned tenant.
Neutron "black magic"™ is used to plumb the network interface of the DB
instance back to the customer tenant on a given port. Security groups are
used to ensure that the DB instances cannot talk to each other at all.

The outstanding tasks with the service tenant model are:
1. Ensure that the security groups are being configured correctly to
prevent horizontal movement if a Trove instance is compromised.
2. Fix the way Trove does backups to object storage, because currently all
backups would go to the same container and there is a risk someone might be
able to restore a backup that is owned by another tenant.

With a shadow tenant, a second tenant is created for every customer tenant
using Trove. As with the service tenant, they cannot see or manipulate
things in this tenant. The network is plumbed back to their primary
(visible) tenant, so they can reach their DB. In this model, only DB
instances owned by them are placed in this tenant. This probably provider
better tenancy isolation, at the cost of the propagation of shadow tenants
for every real tenant.

Have I missed anything?

Cheers,
Bruno

On Wed, Feb 8, 2017 at 2:34 PM, Mark Kirkwood <mark.kirkwood at catalyst.net.nz
> wrote:

> In fact you are not :-) . The relevant code for shadow tenant is in
>
> trove/common/single_tenant_remote.py
>
> Hopefully confusion reduces,
>
> regards
>
> Mark
>
>
> On 06/02/17 17:46, Mark Kirkwood wrote:
>
>> Ah, are you saying that "shadow tenant" is not possible in standard
>> Openstack? (I did wonder if that was the case).
>>
>>
>>
>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170209/c73358a9/attachment.html>