openstack team mailing list archive

[George Reese <george.reese@xxxxxxxxxxxxx>]

Let me put this another way.

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?

-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

Attachment: smime.p7s
Description: S/MIME cryptographic signature