[openstack-dev] Unified Guest Agent proposal

Clint Byrum clint at fewbar.com
Sat Dec 7 16:48:32 UTC 2013

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.

More information about the OpenStack-dev mailing list