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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
