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.kirkw...@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@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac > k >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack