[openstack-dev] Unified Guest Agent proposal

Monty Taylor mordred at inaugust.com
Sat Dec 7 19:13:24 UTC 2013



On 12/07/2013 06:48 PM, Clint Byrum wrote:
> Excerpts from Nicolas Barcet's message of 2013-12-07 01:33:01 -0800:
>> On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum <clint at fewbar.com> wrote:
>>
>>> So what is needed is domain specific command execution and segregation
>>> of capabilities.
>>>
>>
>> To further this, I know that a lot of security minded people consider this
>> types of agent sorts of backdoors. Having one generic "backdoor" that can
>> do everything is something that could be less acceptable as you would not
>> have the choice to pinpoint what you'd like to allow it to do, or then the
>> constraints in terms of fine grained access control becomes huge.   I did
>> not realize this until I too spoke with Scott about this.  Cloud-init, or
>> any such generic tool, should only enable deployment domain specific tool,
>> based on the specific needs of given use case, not become an agent
>> (backdoor) itself.
>>
> 
> Right, we already have a backdoor agent on most OS's, it is called SSH
> and we are used to being _very_ careful about granting SSH access.
> 
>> This said, I imagine we could get some benefits out of a generic
>> framework/library that could be used create such agents in a manner where
>> base authentication and access control is done properly.  This would allow
>> to simplify security analysis and impacts of agents developped using that
>> framework, but the framework itself should never become a generic binary
>> that is deploy everywhere by default and allow way too much in itself.
>>  Binary instances of agents written using the framework would be what could
>> be eventually deployed via cloud-init on a case by case basis.
> 
> I think the mcollective model (see previous message about it) has
> undergone security review and is one to copy. It is mostly what you say.
> The agent is only capable of doing what its plugins can do, and it only
> needs to call out to a single broker, so poking holes for the agents to
> get out is fairly straight forward.

Sake of argument- salt's minion is very similar, and also has a plugin
and acl model - and at least for us doesn't have the ruby issue.

Of course, for _not_ us, it has the python issue. That said- it's
designed to respond to zeromq messages, so writing a salt minion and
plugins in c++ might not be hard to accomplish.

short/medium term - why don't we just actually make use of salt minion
for guest agents? It _is_ python based, which means sending it messages
from trove or savana shouldn't be hard to integrate. It would be
_fascinating_ to see if we could convince them to migrate from direct
zeromq to using it through oslo.messaging. They're also pretty friendly.



More information about the OpenStack-dev mailing list