> -----Original Message----- > From: George Reese [mailto:george.re...@enstratus.com] > > 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....@lists.launchpad.net > >>>> [mailto:openstack- > bounces+ewan.mellor=citrix....@lists.launchpad.net] > >>>> 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.re...@enstratus.com 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.re...@enstratus.com 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@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~openstack > >> More help : https://help.launchpad.net/ListHelp > > > > > > -- > George Reese - Chief Technology Officer, enStratus > e: george.re...@enstratus.com 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
