[openstack-dev] [oslo][nova] Messaging: everything can talk to everything, and that is a bad thing
ayoung at redhat.com
Tue Mar 22 01:43:55 UTC 2016
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:
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
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
2. Compute nodes can only write to response queues in the RPC vhost
3. Compute nodes can only write to notification queus in the
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
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.
More information about the OpenStack-dev