[openstack-dev] [nova][trove] Protected openstack resources

John Garbutt john at johngarbutt.com
Thu Jun 4 10:54:04 UTC 2015

On 3 June 2015 at 20:51, Amrith Kumar <amrith at tesora.com> wrote:
> Several of us including Bruno Lago, Victoria Martinez de la Cruz (vkmc),
> Flavio Percoco, Nikhil Manchanda (SlickNik), Vipul Sabhaya (vipul), Doug
> Shelley (dougshelley66), and several others from the Trove team met in
> Vancouver and were joined by some others (who I do not know by name) from
> other projects. After the summit, I summarized that meeting in the email
> thread here [1].
> In that meeting, and in the course of other conversations, we concluded that
> projects like Trove require the ability to launch instances of resources
> from projects like Nova but bad things happen when a user directly interacts
> with these resources. It would therefore be highly advantageous to have a
> class of instances which are protected from direct user actions.
> The “bad things” described above stem from the fact that the guest agent
> that Trove uses is a component that is on the guest instance and it
> communicates with the other Trove controller services over an oslo.messaging
> message queue. If a guest instance were compromised, the fact that it has a
> connection path to the message queue could become a vulnerability. Deployers
> of Trove have addressed these concerns and are able to operate a secure
> Trove system by launching Nova instances in a different tenant than the end
> user. The changes to Trove for this are currently not part of Trove but will
> be made available shortly.

FWIW, this is basically how Glance uses a multi-tenant Swift to store
images from Nova from various tenants.

I think there are more exciting ways that some folks have brewing that
involve some sort of combination of two tenants, or some such.

> Using oslo.messaging for the communication between Trove controller and the
> guest agents allows deployers to choose the underlying AMQP transport.
> However, oslo.messaging is tightly coupled with AMQP semantics. One proposed
> alternative (zaqar) that could address some of Trove’s issues has no
> integration with oslo.messaging.
> Therefore, to adopt zaqar, Trove would likely have to abandon oslo.messaging
> and integrate tightly with zaqar which strikes many of us as more
> restrictive and less attractive. I know of at least one user of Trove who
> has deployed oslo.messaging with qpid as the underlying transport, rather
> than the more commonly deployed RabbitMQ.
> The request to create an oslo.messaging driver for zaqar (or was it a zaqar
> driver for oslo.messaging) met with some resistance for technical reasons.
> Flavio summarizes it in 2 saying, “This is probably the main reason why
> there's no driver for Zaqar in oslo.messaging. That is, to prevent people
> from actually using Zaqar as a message bus in openstack.”

So you could create a REST API for your agent to talk to. They are
quite well understood, but I have no idea about how your agent talks
to your server, so it could be a terrible idea.

> Other projects like Sahara, and potentially others need a mechanism by which
> to protect their resources from direct manipulation by a user.
> Several conversations ensued with members of Nova team and Bruno drafted a
> write-up summarizing some aspects of the problems. To facilitate a quick
> review of this request, the Trove team has put together a document and it is
> available for review at 3.
> The request is to have Nova and potentially other OpenStack projects review
> the issues being described. They can then provide protected resources that
> projects like Trove can consume.
> Equally, if you work on some other project that could benefit from protected
> resources, please chime in.
> Please post comments on the request on the review (4) and register
> blueprints or work towards delivering these capabilities in your respective
> projects. The request is not prescriptive of how projects like Nova should
> implement these capabilities, it merely requests that they be created.

Why is the running your Nova VMs in a trove or sahara specific tenant
not good enough for your use case?

I am not trying to be difficult, I am just curious about what specific
issues something "better" would need to fix.


More information about the OpenStack-dev mailing list