Open Stack

On 03/22/2016 05:42 PM, Dan Smith wrote:
>>> 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.
> Yep, I think we generally look forward to having all the resize and
> migrate communication coordinated through conductor, but not really for
> security reasons specifically. However, I don't think that pumping
> everything through conductor for, say, api->compute communication is
> something we should do.

So, Api to compute is probably fine as is.  I assume that most of that 
goes in the same queue as the conductor uses.

This assumes that we equally trust conductor and the API server, but I 
think if either is compromised, all bets are off anyway.

>
> As several of us said in IRC yesterday, I'd really like nodes to be able
> to authenticate the sender of a message and not do things based on who
> sent it and whether that makes sense or not.
I read that as "we want to do HMAC outside of the Queue" and,as I said 
before, we tried that.  No one picked it up, Key distribution is a 
nightmare, and unless you do asymmetric cryptography, you need to have a 
separate shared secret for each reader and writer:  there is no pub-sub 
with symmetric crypto.

And we should not be rolling our own security.

>   Adding a bunch of
> broker-specific configuration requirements to achieve a security goal
> (and thus assuming the queue is never compromised) is not really where I
> want to see us go.

Nothing here is broker specific.  The rules are the same for Rabbit, 
QPID and 0MQ.

Message Brokers are a key piece of technology in a lot of enterprise 
software. It is possible to secure them.  Denying the operators the 
ability to secure them because we don't trust the brokers is not fair to 
the operators.

>
> --Dan
>
> __________________________________________________________________________
> 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