[openstack-dev] Unified Guest Agent proposal

Dmitry Mescheryakov dmescheryakov at mirantis.com
Tue Dec 10 16:25:26 UTC 2013


And one more thing,

Sandy Walsh pointed to the client Rackspace developed and use - [1], [2].
Its design is somewhat different and can be expressed by the following
formulae:

App -> Host (XenStore) <-> Guest Agent

(taken from the wiki [3])

It has an obvious disadvantage - it is hypervisor dependent and currently
implemented for Xen only. On the other hand such design should not have
shared facility vulnerability as Agent accesses the server not directly but
via XenStore (which AFAIU is compute node based).

Thanks,

Dmitry


[1] https://github.com/rackerlabs/openstack-guest-agents-unix
[2] https://github.com/rackerlabs/openstack-guest-agents-windows-xenserver
[3] https://wiki.openstack.org/wiki/GuestAgent


2013/12/10 Dmitry Mescheryakov <dmescheryakov at mirantis.com>

> Guys,
>
> I see two major trends in the thread:
>
>  * use Salt
>  * write our own solution with architecture similar to Salt or MCollective
>
> There were points raised pro and contra both solutions. But I have a
> concern which I believe was not covered yet. Both solutions use either
> ZeroMQ or message queues (AMQP/STOMP) as a transport. The thing is there is
> going to be a shared facility between all the tenants. And unlike all other
> OpenStack services, this facility will be directly accessible from VMs,
> which leaves tenants very vulnerable to each other. Harm the facility from
> your VM, and the whole Region/Cell/Availability Zone will be left out of
> service.
>
> Do you think that is solvable, or maybe I overestimate the threat?
>
> Thanks,
>
> Dmitry
>
>
>
>
> 2013/12/9 Dmitry Mescheryakov <dmescheryakov at mirantis.com>
>
>>
>>
>>
>> 2013/12/9 Kurt Griffiths <kurt.griffiths at rackspace.com>
>>
>>>  This list of features makes me *very* nervous from a security
>>> standpoint. Are we talking about giving an agent an arbitrary shell command
>>> or file to install, and it goes and does that, or are we simply triggering
>>> a preconfigured action (at the time the agent itself was installed)?
>>>
>>>
>> I believe the agent must execute only a set of preconfigured actions
>> exactly due to security reasons. It should be up to the using project
>> (Savanna/Trove) to decide which actions must be exposed by the agent.
>>
>>
>>
>>>   From: Steven Dake <sdake at redhat.com>
>>> Reply-To: OpenStack Dev <openstack-dev at lists.openstack.org>
>>> Date: Monday, December 9, 2013 at 11:41 AM
>>> To: OpenStack Dev <openstack-dev at lists.openstack.org>
>>>
>>> Subject: Re: [openstack-dev] Unified Guest Agent proposal
>>>
>>>  In terms of features:
>>> * run shell commands
>>> * install files (with selinux properties as well)
>>> * create users and groups (with selinux properties as well)
>>> * install packages via yum, apt-get, rpm, pypi
>>> * start and enable system services for systemd or sysvinit
>>> * Install and unpack source tarballs
>>> * run scripts
>>> * Allow grouping, selection, and ordering of all of the above operations
>>>
>>> _______________________________________________
>>> 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/20131210/c3bbaee1/attachment.html>


More information about the OpenStack-dev mailing list