Hello,
seems like there is no pushback against decrypting in Javascript. So
unless somebody has something against, I guess it is fine.
I would say that it can be the best, to have both client side decrypting
using JS and server side using Nova. We can let the user decide what to use.
Ladislav
On 01/17/2014 08:05 PM, Alessandro Pilotti wrote:
+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 <ala.rezmer...@cloudwatt.com> 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
