Open Stack

I had a good discussion with the Nova folks in IRC today.

My goal was to understand what could talk to what, and the short 
according to dansmith

" any node in nova land has to be able to talk to the queue for any 
other one for the most part: compute->compute, compute->conductor, 
conductor->compute, api->everything. There might be a few exceptions, 
but not worth it, IMHO, in the current architecture."

Longer conversation is here:
  http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-03-21.log.html#t2016-03-21T17:54:27

Right now, the message queue is a nightmare.  All sorts of sensitive 
information flows over the message queue: Tokens (including admin) are 
the most obvious.  Every piece of audit data. All notifications and all 
control messages.

Before we continue down the path of "anything can talk to anything" can 
we please map out what needs to talk to what, and why?  Many of the use 
cases seem to be based on something that should be kicked off by the 
conductor, such as "migrate, resize, live-migrate" and it sounds like 
there are plans to make that happen.

So, let's assume we can get to the point where, if node 1 needs to talk 
to node 2, it will do so only via the conductor.  With that in place, we 
can put an access control rule in place:

1.  Compute nodes can only read from the queue 
compute.<name>-novacompute-<index>.localdomain
2.  Compute nodes can only write to response queues in the RPC vhost
3.  Compute nodes can only write to notification queus in the 
notification host.

I know that with AMQP, we should be able to identify the writer of a 
message.  This means that each compute node should have its own user.  I 
have identified how to do that for Rabbit and QPid.  I assume for 0mq is 
would make sense to use ZAP (http://rfc.zeromq.org/spec:27) but I'd 
rather the 0mq maintainers chime in here.

I think it is safe (and sane) to have the same use on the compute node 
communicate with  Neutron, Nova, and Ceilometer.  This will avoid a 
false sense of security: if one is compromised, they are all going to be 
compromised.  Plan accordingly.

Beyond that, we should have message broker users for each of the 
components that is a client of the broker.

Applications that run on top of the cloud, and that do not get presence 
on the compute nodes, should have their own VHost.  I see Sahara on my 
Tripleo deploy, but I assume there are others.  Either they completely 
get their own vhost, or the apps should share one separate from the 
RPC/Notification vhosts we currently have.  Even Heat might fall into 
this category.

Note that those application users can be allowed to read from the 
notification queues if necessary.  They just should not be using the 
same vhost for their own traffic.

Please tell me if/where I am blindingly wrong in my analysis.