Open Stack

On Tue, Mar 22, 2016, at 07:00 AM, Doug Hellmann wrote:
> 
> 
> > On Mar 21, 2016, at 9:43 PM, Adam Young <ayoung at redhat.com> wrote:
> > 
> > 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:

If you specifically mean compute nodes by "node 1" and "node 2" that is
something that's being worked towards. If you mean "node" more generally
that's not something that is planned.

> 
> Shouldn't we be trying to remove central bottlenecks by decentralizing
> communications where we can?

I think that's a good goal to continue having. Some deployers have setup
firewalls between compute nodes, or between compute nodes and the
database, so we use the conductor to facilitate communications between
those nodes. But in general we don't want to send all communications
through the conductor. 

> 
> Doug
> 
> 
> > 
> > 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.
> > 
> > 
> > 
> > 
> > 
> > __________________________________________________________________________
> > 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
> 
> __________________________________________________________________________
> 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