Re: [Openstack] Setting VM passwords when not running on Xen
That should be fine, as long as you don't mind a reboot if you want to change your password. That sounds reasonable enough, given the complexity of the alternative. Cheers, John -Original Message- From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: Wednesday, July 4, 2012 10:33 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Setting VM passwords when not running on Xen Scott Moser wrote: Is it for some reason not possible to have code that runs on first instance boot that reads the metadata service (or config drive) and sets the password appropriately? I see no reason why you could not. Windows scripting supported both running scripts at boot and setting user passwords last time I looked :) Using the same mechanism as cloud-init on Linux sounds a lot better to me than a Windows-only hack to enable server-side generation and two-way communication... -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
From: Scott Moser [mailto:ssmos...@gmail.com] On Behalf Of Scott Moser * Cloud-Init / Metadata service (depends on DHCP(?), and not a two-way transport) cloud-init does not require dhcp. It explicitly supports the passing of network interface definitions into it in Ubuntu 12.04. Ie, config-drive with static networking passed in works as it should. Sorry, I was just thinking about relying on DHCP to get the IP address, then using the Metadata Service, on XenAPI were config drive has not been implemented. Its 2012, do we really need to design for the case where IP is broken or not available? I was only really worried about the case of Flat without DHCP that config drive can address. Given things are going this way, I guess that increases the need of implementing config drive for XenAPI. Has anyone already got plans to implement that in Folsom? I might try to find someone in our Citrix team to take a look at implementing that. Cheers, John ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
-Original Message- From: openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix.com@lists.launchpad.n et] On Behalf Of Thierry Carrez Sent: Wednesday, July 4, 2012 10:33 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Setting VM passwords when not running on Xen Scott Moser wrote: Is it for some reason not possible to have code that runs on first instance boot that reads the metadata service (or config drive) and sets the password appropriately? I see no reason why you could not. Windows scripting supported both running scripts at boot and setting user passwords last time I looked :) From a security perspective we want to keep the un-encrypted password (or an encrypted password and the means to decrypt it) out of Nova - hence generating it inside the VM and encrypting with the public key during boot seems stronger. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
Scott Moser wrote: Is it for some reason not possible to have code that runs on first instance boot that reads the metadata service (or config drive) and sets the password appropriately? I see no reason why you could not. Windows scripting supported both running scripts at boot and setting user passwords last time I looked :) Using the same mechanism as cloud-init on Linux sounds a lot better to me than a Windows-only hack to enable server-side generation and two-way communication... -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] 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@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Day, Phil Sent: 03 July 2012 3:07 To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
On Tue, 3 Jul 2012, Day, Phil wrote: 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) ? I'm completely ignorant about windows. Please forgive me. Is it for some reason not possible to have code that runs on first instance boot that reads the metadata service (or config drive) and sets the password appropriately? Or, is there something that makes this actually a nova problem, something that cannot reasonably be solved in the same way such things are solved in other operating systems. Is there no way that you could pass in a public key that would be used for authentication to RDP or whatever you'd do? (grave ignorance of windows). ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
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.garb...@citrix.com] Sent: 03 July 2012 16:41 To: Day, Phil; openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.netmailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]mailto:[mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Day, Phil Sent: 03 July 2012 3:07 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
Interesting idea, that seams reasonable. The password is encrypted when it leaves the VM in the XenServer case too (if I have understood the code correctly). My only concerns are thinking about the more general solution: * It only works on boot, so harder to change password if you forgot it. * I guess it leaves people who are depended on Config drive stuck * We are making more changes to an API we don't really own * How does the VM know to trust it is not an evil metadata service, but I guess the same applies to injecting the SSH keys Cheers, John From: Day, Phil [mailto:philip@hp.com] Sent: 03 July 2012 6:06 To: John Garbutt; openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@lists.launchpad.net) Subject: RE: Setting VM passwords when not running on Xen 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.garb...@citrix.com] Sent: 03 July 2012 16:41 To: Day, Phil; openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.netmailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net]mailto:[mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Day, Phil Sent: 03 July 2012 3:07 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net (openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net) (openstack@lists.launchpad.netmailto:openstack@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
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.garb...@citrix.com] Sent: 03 July 2012 16:41 To: Day, Phil; openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf OfDay, Phil Sent: 03 July 2012 3:07 To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Setting VM passwords when not running on Xen
On Tue, 3 Jul 2012, John Garbutt wrote: 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) cloud-init does not require dhcp. It explicitly supports the passing of network interface definitions into it in Ubuntu 12.04. Ie, config-drive with static networking passed in works as it should. 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. The only thing I don't like about this is there is so very little need for long-lived communication between the hypervisor and the guest. I personally think that cloud-init gets this right. Its goal is to do what it needs to do and get out of the way. It should provide enough to bootstrap you to a more intelligent management framework, such as puppet, chef, juju there are literally dozens of these things that work perfectly well without a hypervisor specific transport. They're widely available, work right now, and don't care if they're running on bare metal, xen, kvm, microsoft virtual server... They just assume that you can connect to them via network, which is a really well defined and tested thing. Its 2012, do we really need to design for the case where IP is broken or not available? I'm not arguing that guest agents are not necessary, I'm arguing that there is extremely little need for them to be hypervisor aware. (yes, there is value in the host being able to request the guest to freeze its filesystem after receiving a API freeze request. However, even *that* could happen over IP). 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@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=eu.citrix@lists.launchpad.net] On Behalf Of Day, Phil Sent: 03 July 2012 3:07 To: openstack@lists.launchpad.net (openstack@lists.launchpad.net) (openstack@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
