Open Stack

John,

Thanks for your note. I've updated the review at https://review.openstack.org/#/c/186357/ with answers to some of your questions (and I added you to that review).

Trove's use-case like some of the other projects listed is different from Glance in that Trove has a guest agent. I've tried to explain that in more detail in patch set 5. I'd appreciate your comments.

Thanks,

-amrith

| -----Original Message-----
| From: John Garbutt [mailto:john at johngarbutt.com]
| Sent: Thursday, June 04, 2015 6:54 AM
| To: OpenStack Development Mailing List (not for usage questions)
| Subject: Re: [openstack-dev] [nova][trove] Protected openstack resources
| 
| 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.
| 
| Thanks,
| John
| 
| __________________________________________________________________________
| OpenStack Development Mailing List (not for usage questions)
| Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev