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

Do you think that is solvable, or maybe I overestimate the threat?



2013/12/9 Dmitry Mescheryakov <>

> 2013/12/9 Kurt Griffiths <>
>>  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 <>
>> Reply-To: OpenStack Dev <>
>> Date: Monday, December 9, 2013 at 11:41 AM
>> To: OpenStack Dev <>
>> 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 mailing list

Reply via email to