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<http://markmail.org/message/cotket76zyhbvj34>].
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. 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<http://markmail.org/message/v3vm7bux5bi6vknu> 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." 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<https://review.openstack.org/#/c/186357>. 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<https://review.openstack.org/#/c/186357>) 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. Thanks, -amrith [1] http://markmail.org/message/cotket76zyhbvj34 [2] http://markmail.org/message/v3vm7bux5bi6vknu [3] https://review.openstack.org/#/c/186357 [4] https://review.openstack.org/#/c/186357
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
