openstack team mailing list archive

["Day, Phil" <philip.day@xxxxxx>]

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@xxxxxxxxxx]
Sent: 03 July 2012 16:41
To: Day, Phil; openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx) (openstack@xxxxxxxxxxxxxxxxxxx)
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@xxxxxxxxxxxxxxxxxxx<mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx> [mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx]<mailto:[mailto:openstack-bounces+john.garbutt=eu.citrix.com@xxxxxxxxxxxxxxxxxxx]> On Behalf Of Day, Phil
Sent: 03 July 2012 3:07
To: openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> (openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>) (openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>)
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