Open Stack

I like the security of this idea, but it would also require that metadata is available outside the vm which it isn't. What about creating a security group that opens a specific port, and run a little webserver on that port in the guest that makes the key available.  That would mean you don't need to modify the metadata server at all.

Vish

On Jul 3, 2012, at 10:05 AM, Day, Phil wrote:

> Thanks John,
>  
> One approach we were wondering about is to have an agent in Windows which:
>  
> o   Generates a random password and sets it for the admin account
> o   Gets the public ssh key from the metadata service
> o   Encrypts the password with the public key
> o   Pushes the encrypted public key back to the metadata server (requires the metadata server to support Push)
>  
> The user can then get the encrypted password from the API and decrypt it with their private key
>  
> The advantage would be that the clear text password never leaves the VM, so there are fewer security concerns about Nova having access to clear text passwords.
>  
> It would also seem to be a small change in the metadata service and no change in the API layer – not sure if there are concerns about what a VM could break if it updates its own metadata, but I guess we could also limit what values can be set.
>  
> Thoughts ?
>  
> Phil
>  
>  
>  
> From: John Garbutt [mailto:John.Garbutt at citrix.com] 
> Sent: 03 July 2012 16:41
> To: Day, Phil; openstack at lists.launchpad.net (openstack at lists.launchpad.net) (openstack at lists.launchpad.net)
> Subject: RE: Setting VM passwords when not running on Xen
>  
> This seemed to crop up quite a lot in different sessions at the Design summit. I am certainly interested in a standard way to inject information into VMs.
>  
> What I think we need is a cross hypervisor two-way guest communication channel that is fairly transparent to the user of that VM (i.e. ideally not a network connection).
>  
> If I understand things correctly, we currently have these setup ideas:
> ·         Config Drive (not supported by XenAPI, but not a two way transport)
> ·         Cloud-Init / Metadata service (depends on DHCP(?), and not a two-way transport)
>  
> But to set the password, we ideally want two way communication. We currently have these:
> ·         XenAPI guest plugin (XenServer specific, uses XenStore, but two way, no networking assumed )
> ·         Serial port (used by http://wiki.libvirt.org/page/Qemu_guest_agent but not supported on XenServer)
>  
> I like the idea of building a common interface (maybe write out to a known file system location) for the above two hypervisor specific mechanisms. The agent should be able to pick which mechanism works. Then on top of that, we could write a common agent that can be shared for all the different hypervisors. You could also fallback to the metadata service and config drive when no two way communication is available.
>  
> I would love this Guest Agent to be an OpenStack project that can then be up streamed into many Linux distribution cloud images.
>  
> Sadly, I don’t have any time to work on this right now, but hopefully that will change in the near future.
>  
> Cheers,
> John
>  
> From: openstack-bounces+john.garbutt=eu.citrix.com at lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix.com at lists.launchpad.net] On Behalf OfDay, Phil
> Sent: 03 July 2012 3:07
> To: openstack at lists.launchpad.net (openstack at lists.launchpad.net) (openstack at lists.launchpad.net)
> Subject: [Openstack] Setting VM passwords when not running on Xen
>  
> Hi Folks,
>  
> Is anyone else looking at how to support images that need a password rather than an ssh key (windows) on hypervisors that don’t support set_admin_password (e.g. libvirt) ?
>  
> Thanks
> Phil  
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120703/ffdb01a7/attachment.html>