← Back to team overview

openstack team mailing list archive

Re: 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



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


Follow ups

References