> 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
