Re: [Openstack] Handling of adminPass is arguably broken (essex)
Those agents use the Xen/XenAPI specific stuff called xenstore. There was talk of extending cloud-init and the metadata service to support some kind of password generation on boot or at a poll interval, but I don't remember that conversation getting too far. Anyone one else remember what came of those ideas? John From: openstack-bounces+john.garbutt=citrix@lists.launchpad.net [mailto:openstack-bounces+john.garbutt=citrix@lists.launchpad.net] On Behalf Of Sam Stoelinga Sent: 28 November 2012 06:26 To: Pádraig Brady Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Handling of adminPass is arguably broken (essex) Hi, Just noticed the following two projects: https://github.com/rackspace/openstack-guest-agents-windows-xenserver https://github.com/rackspace/openstack-guest-agents-unix Would those be useful in creating an agent like Vish described? It seems they currently only support Xen? Haven't taken a deep look yet. a) put a public key on the instance via metadata or config drive (for ease of use this could actually just be the ssh public key you normally use for logging into the vm). b) have a daemon in the windows instance that: * generates a random password * sets the administrator password to the random password * encrypts it with the public key * serves the encrypted password over https on a known port (say ) c) open up port () in the instance's security group d) retrieve the encrypted password and decrypt it e) close port () in the instances security group Was wondering if it's planned for Grizzly a way to change the password for libvirt/kvm guests (unix and windows)? Is there any blueprint available? Sam On Sat, Nov 3, 2012 at 3:15 AM, Pádraig Brady p...@draigbrady.commailto:p...@draigbrady.com wrote: On 11/02/2012 07:03 PM, Lars Kellogg-Stedman wrote: On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote: The new config drive code defaults to iso-9660, so that should work. The vfat version should probably create a partition table. Is that what Folsom is using? Or is it new-er than that? That's in Folsom ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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] Handling of adminPass is arguably broken (essex)
Hi, Just noticed the following two projects: https://github.com/rackspace/openstack-guest-agents-windows-xenserver https://github.com/rackspace/openstack-guest-agents-unix Would those be useful in creating an agent like Vish described? It seems they currently only support Xen? Haven't taken a deep look yet. a) put a public key on the instance via metadata or config drive (for ease of use this could actually just be the ssh public key you normally use for logging into the vm). b) have a daemon in the windows instance that: * generates a random password * sets the administrator password to the random password * encrypts it with the public key * serves the encrypted password over https on a known port (say ) c) open up port () in the instance's security group d) retrieve the encrypted password and decrypt it e) close port () in the instances security group Was wondering if it's planned for Grizzly a way to change the password for libvirt/kvm guests (unix and windows)? Is there any blueprint available? Sam On Sat, Nov 3, 2012 at 3:15 AM, Pádraig Brady p...@draigbrady.com wrote: On 11/02/2012 07:03 PM, Lars Kellogg-Stedman wrote: On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote: The new config drive code defaults to iso-9660, so that should work. The vfat version should probably create a partition table. Is that what Folsom is using? Or is it new-er than that? That's in Folsom __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://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] Handling of adminPass is arguably broken (essex)
On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote: The new config drive code defaults to iso-9660, so that should work. The vfat version should probably create a partition table. Is that what Folsom is using? Or is it new-er than that? -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
On 11/02/2012 07:03 PM, Lars Kellogg-Stedman wrote: On Thu, Nov 01, 2012 at 11:03:14AM -0700, Vishvananda Ishaya wrote: The new config drive code defaults to iso-9660, so that should work. The vfat version should probably create a partition table. Is that what Folsom is using? Or is it new-er than that? That's in Folsom ___ 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] Handling of adminPass is arguably broken (essex)
Honestly I think the entire idea of passing a password in to the instance at boot time is insecure and flawed. I think that the use of a configuration drive is a reasonably way to provide configuration information to an instance, and it's more secure than the metadata server. In any case, the problem extends beyond passwords; the way injected network configuration and ssh keys are handled also make unreasonable assumptions about the target operating system and suffer from the same problems as password provisioning. I've put together a patch that solves my needs, available here: https://github.com/seas-computing/nova/commits/lars/admin_pass That branch incorporates also changes from the EPEL packages for 2012.1.3 (since this is what we're running). It seems to work so far, although now we're facing a new problem: the adminPass generated by OpenStack is provided to people running the nova boot ... command line clients but (a) isn't exposed in the web ui and (b) doesn't appear to be otherwise accessible (e.g., via euca-describe-password). -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
On 11/1/12 9:36 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: Honestly I think the entire idea of passing a password in to the instance at boot time is insecure and flawed. I think that the use of a configuration drive is a reasonably way to provide configuration information to an instance, and it's more secure than the metadata server. In any case, the problem extends beyond passwords; the way injected network configuration and ssh keys are handled also make unreasonable assumptions about the target operating system and suffer from the same problems as password provisioning. I've put together a patch that solves my needs, available here: https://github.com/seas-computing/nova/commits/lars/admin_pass That branch incorporates also changes from the EPEL packages for 2012.1.3 (since this is what we're running). It seems to work so far, although now we're facing a new problem: the adminPass generated by OpenStack is provided to people running the nova boot ... command line clients but (a) isn't exposed in the web ui and (b) doesn't appear to be otherwise accessible (e.g., via euca-describe-password). Hey Lars, (a) sounds like a bug in Horizon if that's not viewable immediately after creating the instance. If we can confirm that is the case and file a bug, that'd be good. It just comes back via the API so it should be available to any client. (b) is definitely not going to work - we don't store the password at all, an intentional decision. Gabe -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
On Thu, Nov 01, 2012 at 02:07:08PM +, Gabe Westmaas wrote: (a) sounds like a bug in Horizon if that's not viewable immediately after creating the instance. Horizon doesn't display any information after booting an instance...it takes you directly to the Instances screen. So not so much a bug but a design decision, I think. (b) is definitely not going to work - we don't store the password at all, an intentional decision. I figured that, although it appears that Amazon has made a different decision. I'm just looking for a way to make this work :). -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
The best idea I've heard for a secure windows password is the following: a) put a public key on the instance via metadata or config drive (for ease of use this could actually just be the ssh public key you normally use for logging into the vm). b) have a daemon in the windows instance that: * generates a random password * sets the administrator password to the random password * encrypts it with the public key * serves the encrypted password over https on a known port (say ) c) open up port () in the instance's security group d) retrieve the encrypted password and decrypt it e) close port () in the instances security group +1 for this. As a side note, there's probably work to be done to ensure that the instance actually has good entropy and can create a truly random password. Nevertheless, this entropy problem could be solved separately from what Vish describes above. -bryan ___ 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] Handling of adminPass is arguably broken (essex)
On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote: TL;DR: The way OpenStack handles the adminPass attribute during metadata injection is not useful on operating systems without an /etc/passwd and /etc/shadow. I would like to make the adminPass value available on a Windows instance, and this is my proposal for how to do it. Oh geez, it gets worse. The configuration disk created by OpenStack is a whole-disk filesystem (no partition map), so Windows thinks it's all unallocated space...so even with my patches in place I still can't get at the data. I can see I'm traveling through largely unexplored territory here. -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
On 11/01/2012 05:14 PM, Lars Kellogg-Stedman wrote: On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote: TL;DR: The way OpenStack handles the adminPass attribute during metadata injection is not useful on operating systems without an /etc/passwd and /etc/shadow. I would like to make the adminPass value available on a Windows instance, and this is my proposal for how to do it. Oh geez, it gets worse. The configuration disk created by OpenStack is a whole-disk filesystem (no partition map), so Windows thinks it's all unallocated space...so even with my patches in place I still can't get at the data. I can see I'm traveling through largely unexplored territory here. It's somewhere on my TODO list to refactor the new config disk stuff to reuse the mounting logic from virt/disk/ and thus could support partitions if required. cheers, Pádraig. ___ 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] Handling of adminPass is arguably broken (essex)
On Nov 1, 2012, at 10:14 AM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: On Wed, Oct 31, 2012 at 09:09:14PM -0400, Lars Kellogg-Stedman wrote: TL;DR: The way OpenStack handles the adminPass attribute during metadata injection is not useful on operating systems without an /etc/passwd and /etc/shadow. I would like to make the adminPass value available on a Windows instance, and this is my proposal for how to do it. Oh geez, it gets worse. The configuration disk created by OpenStack is a whole-disk filesystem (no partition map), so Windows thinks it's all unallocated space...so even with my patches in place I still can't get at the data. I can see I'm traveling through largely unexplored territory here. The new config drive code defaults to iso-9660, so that should work. The vfat version should probably create a partition table. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Handling of adminPass is arguably broken (essex)
TL;DR: The way OpenStack handles the adminPass attribute during metadata injection is not useful on operating systems without an /etc/passwd and /etc/shadow. I would like to make the adminPass value available on a Windows instance, and this is my proposal for how to do it. I've been putting together a Windows 2008 server image for deploying in our OpenStack environment. I started by setting it up to act just like our Linux images: - It has sshd running as a service via Cygwin - It runs a script at startup to pull an ssh key from the metadata server for the Administrator account. This works great! But I've had some push-back from folks who argue that this process won't be familiar to a typical Windows administrator, so I started trying to figure how to get an administrator password either (a) into the instance from the person creating it, or (b) back to the person creating the instance after generating the password. (a) is relatively easy to do via the user-data attribute, and I have a prototype of that working. However... One of my colleagues mention that there was some mechanism for injecting passwords into instances -- which sounds perfect. Based on my efforts in #openstack, it appears that very few people take advantage of this feature or even know how it operates, so I went diving through the code and eventually found myself in nova/virt/disk/api.py, where I discovered that even with config_drive=True, nova will attempt to copy /etc/passwd and /etc/shadow (which don't exist) off the config drive to modify them locally. This obviously fails, leaving the admin password inaccessible. I would like to propose that if config_drive=True, that the admin password simply get written into a file, where it could be used by operating systems without an /etc/passwd or /etc/shadow file. If this sounds like a good idea, I'll work up a patch. It seems that for this to work, inject_data needs to know whether or not it's targeting a config_drive or an actual partition...and so does inject_data_into_fs. Maybe something like: In virt/libvirt/connection.py: disk.inject_data(injection_path, key, net, metadata, admin_pass, files, partition=target_partition, use_cow=FLAGS.use_cow_images, config_drive=config_drive) And in virt/disk/api.py: def inject_data(image, key=None, net=None, metadata=None, admin_password=None, files=None, partition=None, use_cow=False, config_drive=False): ... inject_data_into_fs(img.mount_dir, key, net, metadata, admin_password, files, config_drive=False) ... def inject_data_into_fs(fs, key, net, metadata, admin_password, files, config_drive=False): ... if admin_password: if config_drive: _inject_admin_password_as_file_into_fs(admin_password, fs) else: _inject_admin_password_into_fs(admin_password, fs) Thoughts? -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
Just fyi, the cloud-init format 'spec' has something similar that bypasses the file injection (which is a bad/insecure/incompatible concept that needs to be gotten rid of imho) by having the following syntax it understands: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc /examples/cloud-config-user-groups.txt Is there anyway a windows version of cloud-init could be done, either ported, or patched, or a service like cloud-init could be added to windows images (using a startup program in the windows image that could just be a call-out to a python interpreter or something different...). In the linux image world it is pretty common to have a version of cloud-init be bootstrapped into the image so it would seem like windows could be similar. On 10/31/12 6:09 PM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: TL;DR: The way OpenStack handles the adminPass attribute during metadata injection is not useful on operating systems without an /etc/passwd and /etc/shadow. I would like to make the adminPass value available on a Windows instance, and this is my proposal for how to do it. I've been putting together a Windows 2008 server image for deploying in our OpenStack environment. I started by setting it up to act just like our Linux images: - It has sshd running as a service via Cygwin - It runs a script at startup to pull an ssh key from the metadata server for the Administrator account. This works great! But I've had some push-back from folks who argue that this process won't be familiar to a typical Windows administrator, so I started trying to figure how to get an administrator password either (a) into the instance from the person creating it, or (b) back to the person creating the instance after generating the password. (a) is relatively easy to do via the user-data attribute, and I have a prototype of that working. However... One of my colleagues mention that there was some mechanism for injecting passwords into instances -- which sounds perfect. Based on my efforts in #openstack, it appears that very few people take advantage of this feature or even know how it operates, so I went diving through the code and eventually found myself in nova/virt/disk/api.py, where I discovered that even with config_drive=True, nova will attempt to copy /etc/passwd and /etc/shadow (which don't exist) off the config drive to modify them locally. This obviously fails, leaving the admin password inaccessible. I would like to propose that if config_drive=True, that the admin password simply get written into a file, where it could be used by operating systems without an /etc/passwd or /etc/shadow file. If this sounds like a good idea, I'll work up a patch. It seems that for this to work, inject_data needs to know whether or not it's targeting a config_drive or an actual partition...and so does inject_data_into_fs. Maybe something like: In virt/libvirt/connection.py: disk.inject_data(injection_path, key, net, metadata, admin_pass, files, partition=target_partition, use_cow=FLAGS.use_cow_images, config_drive=config_drive) And in virt/disk/api.py: def inject_data(image, key=None, net=None, metadata=None, admin_password=None, files=None, partition=None, use_cow=False, config_drive=False): ... inject_data_into_fs(img.mount_dir, key, net, metadata, admin_password, files, config_drive=False) ... def inject_data_into_fs(fs, key, net, metadata, admin_password, files, config_drive=False): ... if admin_password: if config_drive: _inject_admin_password_as_file_into_fs(admin_password, fs) else: _inject_admin_password_into_fs(admin_password, fs) Thoughts? -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist | http://ac.seas.harvard.edu/ Academic Computing| http://code.seas.harvard.edu/ Harvard School of Engineering | and Applied Sciences| ___ 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] Handling of adminPass is arguably broken (essex)
On Oct 31, 2012, at 7:04 PM, Lars Kellogg-Stedman l...@seas.harvard.edu wrote: Injection via files on a configuration disk seems to me the best way to handle security credentials like this, because disks in many cases require privileges to mount on a system and the configuration script can delete the credentials file after processing it. Honestly I think the entire idea of passing a password in to the instance at boot time is insecure and flawed. The best idea I've heard for a secure windows password is the following: a) put a public key on the instance via metadata or config drive (for ease of use this could actually just be the ssh public key you normally use for logging into the vm). b) have a daemon in the windows instance that: * generates a random password * sets the administrator password to the random password * encrypts it with the public key * serves the encrypted password over https on a known port (say ) c) open up port () in the instance's security group d) retrieve the encrypted password and decrypt it e) close port () in the instances security group for extra security you could use make daemon run for a certain amount of time on initial boot or have a a specific url on the port that stops the daemon. If we could collaborate on a daemon that does this on the guest side then we could actually create a nova command that would do all of the above and display the password to the user. In fact this would work for non-windows vms as well. nova get-password uuid Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
