Open Stack

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
> Thanks,
>
> Dmitry
>
>
>
> 2013/12/11 Fox, Kevin M <kevin.fox at pnnl.gov <mailto:kevin.fox at pnnl.gov>>
>
>     Yeah. Its likely that the metadata server stuff will get more
>     scalable/hardened over time. If it isn't enough now, lets fix it
>     rather then coming up with a new system to work around it.
>
>     I like the idea of using the network since all the hypervisors
>     have to support network drivers already. They also already have to
>     support talking to the metadata server. This keeps OpenStack out
>     of the hypervisor driver business.
>
>     Kevin
>
>     ________________________________________
>     From: Clint Byrum [clint at fewbar.com <mailto:clint at fewbar.com>]
>     Sent: Tuesday, December 10, 2013 1:02 PM
>     To: openstack-dev
>     Subject: Re: [openstack-dev] Unified Guest Agent proposal
>
>     Excerpts from Dmitry Mescheryakov's message of 2013-12-10 12:37:37
>     -0800:
>     > >> What is the exact scenario you're trying to avoid?
>     >
>     > It is DDoS attack on either transport (AMQP / ZeroMQ provider)
>     or server
>     > (Salt / Our own self-written server). Looking at the design, it
>     doesn't
>     > look like the attack could be somehow contained within a tenant
>     it is
>     > coming from.
>     >
>
>     We can push a tenant-specific route for the metadata server, and a
>     tenant
>     specific endpoint for in-agent things. Still simpler than
>     hypervisor-aware
>     guests. I haven't seen anybody ask for this yet, though I'm sure
>     if they
>     run into these problems it will be the next logical step.
>
>     > In the current OpenStack design I see only one similarly vulnerable
>     > component - metadata server. Keeping that in mind, maybe I just
>     > overestimate the threat?
>     >
>
>     Anything you expose to the users is "vulnerable". By using the
>     localized
>     hypervisor scheme you're now making the compute node itself
>     vulnerable.
>     Only now you're asking that an already complicated thing
>     (nova-compute)
>     add another job, rate limiting.
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/0d06d8ec/attachment.html>