openstack team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: George Reese [mailto:george.reese@xxxxxxxxxxxxx]
> 
> You have an option of two methods: one more intrusive and one less
> intrusive. The more intrusive approach gives the owner of the guest
> less control and is less transparent. The less intrusive approach gives
> the guest owner more control and is more transparent.
> 
> Why opt for the more intrusive option?

It's not more intrusive -- you can always turn it off -- and it's a lot simpler.  Simple is good.

Ewan.


> 
> -George
> 
> On Mar 3, 2011, at 1:22 PM, Rick Clark wrote:
> 
> > On 03/03/2011 12:40 PM, George Reese wrote:
> >> So why don't we give the provider root access to our machines?
> >>
> > to be fair, a provider owns the hypervisor and storage, I would
> always
> > assume providers have root equivalent access if they want it.
> >
> >
> >> Because there's a line between what is our responsibility and what
> is that of the provider. Agents need to be invited elements, not
> required elements.
> >
> > Agreed.  But it is acceptable to require an agent for certain
> features a
> > provider offers, i.e. password changes or support access.  In the
> end,
> > we can't force anyone to run an agent anyway .
> >
> >
> >> -George
> >>
> >> On Mar 3, 2011, at 12:36 PM, Ewan Mellor wrote:
> >>
> >>> The hypervisor can set your VM's memory or disk contents to
> anything it likes, set your registers to anything it likes, read all of
> memory, disk, and network, or even redirect you to a malicious TPM.  If
> you are going to execute code on a VM in the cloud, then you _have_ to
> trust the service provider -- no crypto in the world can protect you.
> >>>
> >>> In-guest agents just make it easier to do things, and they make it
> more transparent to the customer what we're doing and how.  There's no
> fundamental change in trust by having them.
> >>>
> >>> Ewan.
> >>>
> >>>> -----Original Message-----
> >>>> From: openstack-bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx
> >>>> [mailto:openstack-
> bounces+ewan.mellor=citrix.com@xxxxxxxxxxxxxxxxxxx]
> >>>> On Behalf Of George Reese
> >>>> Sent: 03 March 2011 15:36
> >>>> To: Ed Leafe
> >>>> Cc: Openstack; Mark Washenberger
> >>>> Subject: Re: [Openstack] OS API server password generation
> >>>>
> >>>> I don't agree with this approach.
> >>>>
> >>>> The current Cloud Servers approach is flawed. I wrote about this a
> year
> >>>> ago:
> >>>>
> >>>> http://broadcast.oreilly.com/2010/02/the-sacred-barrier.html
> >>>>
> >>>> It's a mistake to send OpenStack pursuing a flaw in Cloud Servers.
> >>>>
> >>>> -George
> >>>>
> >>>> On Mar 3, 2011, at 9:32 AM, Ed Leafe wrote:
> >>>>
> >>>>> On Mar 3, 2011, at 8:40 AM, George Reese wrote:
> >>>>>
> >>>>>> Any mechanism that requires an agent or requires any ability of
> the
> >>>> hypervisor or cloud platform to inject a password creates trust
> issues.
> >>>> In particular, the hypervisor and platform should avoid operations
> that
> >>>> reach into the guest. The guest should have the option of complete
> >>>> control over its data.
> >>>>>
> >>>>> 	Please understand that this is a Rackspace-specific use
> case. It
> >>>> is not an OpenStack standard by any means. That's why this action
> is in
> >>>> a specific agent, not in the main OpenStack compute codebase. On
> an
> >>>> OpenStack list, we should be discussing the OpenStack code, not
> >>>> Rackspace's customization of that code for our use cases.
> >>>>> 	Rackspace sells support. Customers are free to
> >>>> enable/disable/change whatever they want, with the understanding
> that
> >>>> it will limit the ability to directly support their instances.
> That
> >>>> decision is up to each customer, but our default is to build in
> the
> >>>> support mechanism. Other OpenStack deployments will choose to do
> things
> >>>> quite differently, I'm sure. It's even likely that in the future
> >>>> Rackspace may add a secure option like you describe, but for now
> we're
> >>>> focusing on parity with the current Cloud Servers product, and
> that
> >>>> includes password injection at creation.
> >>>>>
> >>>>>
> >>>>> -- Ed Leafe
> >>>>>
> >>>>>
> >>>>>
> >>>> --
> >>>> George Reese - Chief Technology Officer, enStratus
> >>>> e: george.reese@xxxxxxxxxxxxx    t: @GeorgeReese    p:
> +1.207.956.0217
> >>>> f: +1.612.338.5041
> >>>> enStratus: Governance for Public, Private, and Hybrid Clouds -
> >>>> @enStratus - http://www.enstratus.com To schedule a meeting with
> me:
> >>>> http://tungle.me/GeorgeReese
> >>>>
> >>>>
> >> --
> >> George Reese - Chief Technology Officer, enStratus
> >> e: george.reese@xxxxxxxxxxxxx    t: @GeorgeReese    p:
> +1.207.956.0217    f: +1.612.338.5041
> >> enStratus: Governance for Public, Private, and Hybrid Clouds -
> @enStratus - http://www.enstratus.com
> >> To schedule a meeting with me: http://tungle.me/GeorgeReese
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> 
> --
> George Reese - Chief Technology Officer, enStratus
> e: george.reese@xxxxxxxxxxxxx    t: @GeorgeReese    p: +1.207.956.0217
> f: +1.612.338.5041
> enStratus: Governance for Public, Private, and Hybrid Clouds -
> @enStratus - http://www.enstratus.com
> To schedule a meeting with me: http://tungle.me/GeorgeReese
> 
>