Open Stack

Sounds like a pretty neat idea.

I like it!

Another idea: instead of saying pushing for one agent to rule them all why don't we come up with a desired reference spec (maybe including a reference implementation?) that the salt, chef, mcollective, (other...) can base theres off of. In a way this creates a standard agent that can also be compatible with other agents (as long as said agents implement the same spec). Said spec could be based off a combination of the salt one and the rackspace one (...) but instead of "pushing" a single agent, openstack would "push" a spec instead.

Sent from my really tiny device...

> On Dec 7, 2013, at 11:17 AM, "Monty Taylor" <mordred at inaugust.com> wrote:
> 
> 
> 
>> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev