On 12/12/2013 02:19 PM, Clint Byrum wrote:
Excerpts from Steven Dake's message of 2013-12-12 12:32:55 -0800:
On 12/12/2013 10:24 AM, Dmitry Mescheryakov wrote:
Clint, Kevin,
Thanks for reassuring me :-) I just wanted to make sure that having
direct access from VMs to a single facility is not a dead end in terms
of security and extensibility. And since it is not, I agree it is much
simpler (and hence better) than hypervisor-dependent design.
Then returning to two major suggestions made:
* Salt
* Custom solution specific to our needs
The custom solution could be made on top of oslo.messaging. That gives
us RPC working on different messaging systems. And that is what we
really need - an RPC into guest supporting various transports. What it
lacks at the moment is security - it has neither authentication nor ACL.
Salt also provides RPC service, but it has a couple of disadvantages:
it is tightly coupled with ZeroMQ and it needs a server process to
run. A single transport option (ZeroMQ) is a limitation we really want
to avoid. OpenStack could be deployed with various messaging
providers, and we can't limit the choice to a single option in the
guest agent. Though it could be changed in the future, it is an
obstacle to consider.
Running yet another server process within OpenStack, as it was already
pointed out, is expensive. It means another server to deploy and take
care of, +1 to overall OpenStack complexity. And it does not look it
could be fixed any time soon.
For given reasons I give favor to an agent based on oslo.messaging.
An agent based on oslo.messaging is a potential security attack vector
and a possible scalability problem. We do not want the guest agents
communicating over the same RPC servers as the rest of OpenStack
I don't think we're talking about agents talking to the exact same
RabbitMQ/Qpid/etc. bus that things under the cloud are talking to. That
would definitely raise some eyebrows. No doubt it will be in the realm
of possibility if deployers decide to do that, but so is letting your
database server sit on the same flat network as your guests.
This is my concern.
I have a hard time seeing how using the same library is a security
risk though.
Yes, unless the use of the library is abused by the deployer, is itself
not a security risk.
Regards
-steve
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
