So why don't we give the provider root access to our machines? 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.
-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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
