Open Stack

On 12/07/2013 11:09 PM, Joshua Harlow wrote:
> 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.

I think that's overreaching and unlikely to be helpful longterm
(although, in a perfect world...)

Let me be clear about what I'm suggesting - on a topic such as this, I
think it's very easy to quickly get confusing.

The problem isn't that the world needs a unified guest agent - we'll
NEVER get that to happen - it's that we need one for our services to use
to do guest agent things. It's not important that our guest agent is the
same at the guest agent systems that might be running at a given
location. For instance, if someone uses puppet and mcollective at a site
to deploy nova and trove, it's not important that the guest agent that
trove uses to perform tasks in guests it spawns be the same as the
orchestration system that the admins of that cloud use to perform config
management tasks on their servers. So - it's not important that their
personal deployment preferences be honored.

I suggested salt because we could very easily make trove and savana into
salt masters (if we wanted to) just by having them import salt library
and run an api call. When they spin up nodes using heat, we could easily
have that to the cert exchange - and the admins of the site need not
know _anything_ about salt, puppet or chef - only about trove or savana.


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