<div dir="ltr">As a result of this discussion, I think we need also involve Marconi  team to this discussion. (I am sorry for changing the Subject).<div><br></div><div>I am not very familiar with Marconi project details, but at first look it looks like it can help to setup separate MQ infrastructure for agent <-> service communication.</div>
<div><br></div><div>I don't have any specific design suggestions and I hope Marconi team will help us to find a right approach. </div><div><br></div><div>It looks like that option with oslo.message framework has now lower priority due to security reasons. </div>
<div><br></div><div>Thanks</div><div>Georgy<br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 11:33 AM, Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 03/06/2014 10:24 AM, Daniel P. Berrange wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Mar 06, 2014 at 07:25:37PM +0400, Dmitry Mescheryakov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello folks,<br>
<br>
A number of OpenStack and related projects have a need to perform<br>
operations inside VMs running on OpenStack. A natural solution would<br>
be an agent running inside the VM and performing tasks.<br>
<br>
One of the key questions here is how to communicate with the agent. An<br>
idea which was discussed some time ago is to use oslo.messaging for<br>
that. That is an RPC framework - what is needed. You can use different<br>
transports (RabbitMQ, Qpid, ZeroMQ) depending on your preference or<br>
connectivity your OpenStack networking can provide. At the same time<br>
there is a number of things to consider, like networking, security,<br>
packaging, etc.<br>
<br>
So, messaging people, what is your opinion on that idea? I've already<br>
raised that question in the list [1], but seems like not everybody who<br>
has something to say participated. So I am resending with the<br>
different topic. For example, yesterday we started discussing security<br>
of the solution in the openstack-oslo channel. Doug Hellmann at the<br>
start raised two questions: is it possible to separate different<br>
tenants or applications with credentials and ACL so that they use<br>
different queues? My opinion that it is possible using RabbitMQ/Qpid<br>
management interface: for each application we can automatically create<br>
a new user with permission to access only her queues. Another question<br>
raised by Doug is how to mitigate a DOS attack coming from one tenant<br>
so that it does not affect another tenant. The thing is though<br>
different applications will use different queues, they are going to<br>
use a single broker.<br>
</blockquote>
Looking at it from the security POV, I'd absolutely not want to<br>
have any tenant VMs connected to the message bus that openstack<br>
is using between its hosts. Even if you have security policies<br>
in place, the inherent architectural risk of such a design is<br>
just far too great. One small bug or misconfiguration and it<br>
opens the door to a guest owning the entire cloud infrastructure.<br>
Any channel between a guest and host should be isolated per guest,<br>
so there's no possibility of guest messages finding their way out<br>
to either the host or to other guests.<br>
<br>
If there was still a desire to use oslo.messaging, then at the<br>
very least you'd want a completely isolated message bus for guest<br>
comms, with no connection to the message bus used between hosts.<br>
Ideally the message bus would be separate per guest too, which<br>
means it ceases to be a bus really - just a point-to-point link<br>
between the virt host + guest OS that happens to use the oslo.messaging<br>
wire format.<br>
<br>
Regards,<br>
Daniel<br>
</blockquote></div></div>
I agree and have raised this in the past.<br>
<br>
IMO oslo.messaging is a complete nonstarter for guest communication because of security concerns.<br>
<br>
We do not want guests communicating on the same message bus as infrastructure.  The response to that was "well just have all the guests communicate on their own unique messaging server infrastructure".  The downside of this is one guests activity could damage a different guest because of a lack of isolation and the nature in which message buses work.  The only workable solution which ensures security is a unique message bus per guest - which means a unique daemon per guest.  Surely there has to be a better way.<br>

<br>
The idea of isolating guests on a user basis, but allowing them to all exchange messages on one topic doesn't make logical sense to me.  I just don't think its possible, unless somehow rpc delivery were changed to deliver credentials enforced by the RPC server in addition to calling messages.  Then some type of credential management would need to be done for each guest in the infrastructure wishing to use the shared message bus.<br>

<br>
The requirements of oslo.messaging solution for a shared agent is that the agent would only be able to listen and send messages directed towards it (point to point) but would be able to publish messages to a topic for server consumption (the agent service, which may be integrated into other projects).  This way any number of shared agents could communicate to one agent service, but those agents would be isolated from one another.<br>

<br>
Perhaps user credentials could be passed as well in the delivery of each RPC message, but that means putting user credentials in the VM to start the communication.  Bootstrapping seems like a second obvious problem with this model.<br>

<br>
I prefer a point to point model, much as the metadata service works today.  Although rpc.messaging is a really nice framework (I know, I just ported heat to oslo.messaging!) it doesn't fit this problem well because of the security implications.<br>

<br>
Regards<br>
-steve<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><font color="#999999"><span style="background-color:rgb(255,255,255)">Georgy Okrokvertskhov<br>
Architect,<br><span style="font-family:arial;font-size:small">OpenStack Platform Products,</span><br>
Mirantis</span><br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><br></div>
</div></div></div></div>