Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev