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
