+1 Nova's get-password is corrently the only safe way from a security perspective to handle guest passwords.
This feature needs to be mirrored in Horizon, otherwise most users will continue to resort to unsafe solutions like the clear text admin_pass due to lack of practical alternatives. The design and implementation proposed by Ala is IMO a good one. It provides a UX quite similar to what other cloud environments like AWS offer with the additional bonus of keeping any sensitive data on the client side. Alessandro P.S.: Sorry for replying only now, I somehow skipped the original email in the ML! On 17 Dec 2013, at 13:58 , Ala Rezmerita <[email protected]> wrote: > Hi all, > > I would like to get your opinion/feedback about the implementation of the > blueprint "Decrypt and display VM generated password"[1] > > Our use case is primarily targeting Windows instances with cloudbase-init, > but the functionality can be also used on Linux instances. > The general idea of this blueprint is to give the user the ability to > retrieve, through Horizon, administrative password for his Windows session. > > There is two ways for the user to set/get his password on cloudbase-init > Windows instances: > - The user sets the desired password as admin_pass key/value as metadata of > the new server. Example : https://gist.github.com/arezmerita/8001673. In this > case the password is visible in instance description, in metatada section. > - The user do not set his password. In this case the cloudbase-init will > generate a random password, encrypt it with user provided public key, and > will send the result to the metadata server. The only way to get the clear > password is to use API/nova client and provide the private key. Example: > nova get-password . The novaclient will retrieve encrypted password from > Nova and will use locally the private key in order to decrypt the password. > > Now about our blueprint implementation: > - We add an new action "Retrieve password" on an instance, that shows a form > displaying the key pair name used to boot the instance and the encrypted > password. The user can provide its private key, that will be used ONLY on the > client side for password decryption using JSEncrypt library[2]. > - We choose to not send the private key over the network (for decryption on > server side), because we consider that the user should not be forced to share > this information with the cloud operator. > Some may argue that the connection is protected, and we are already passing > sensitive data over the network. However, openstack user password/tokens are > "openstack" sensitive data, they are related to the "openstack" user. User's > private key on the other hand, is something personal to the user, > "not-openstack" related. > > What do you think? > > Note: On the whiteboard of the blueprint[1] I provided two demos and some > instructions of how to test this functionality with Linux instances. > > Thanks, > > References: > [1] > https://blueprints.launchpad.net/horizon/+spec/decrypt-and-display-vm-generated-password > [2] JSEncrypt library http://travistidwell.com/jsencrypt/ > > > Ala Rezmerita > Software Engineer || Cloudwatt > M: (+33) 06 77 43 23 91 > Immeuble Etik > 892 rue Yves Kermen > 92100 Boulogne-Billancourt – France > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
