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" <mord...@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 <cl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
