Excerpts from CARVER, PAUL's message of 2016-03-23 08:40:43 -0700: > Jagga Soorma wrote: > > >Currently when using the openstack api I have to save my password in clear > >text in > >the OS_PASSWORD environment variable. Is there a more secure way to use the > >openstack api without having to either store this password in clear text or > >enter the > >password manually every time I run a openstack command? Is there some way > >that > >I can use a token id? I have tried but can't seem to get it to work and not > >sure what > >else is possible. > > If the token will allow you to use services and you store the token in clear > text then > you’ve only managed to rename your password to token without adding any > security. >
That's not entirely true, as the token can be revoked and has an expiration time. Still, it's not _much_ better. > What you need to think about is what are you willing to type and when are you > willing > to type it. I don’t know if anyone has a polished “official” implementation, > but a couple > of options: > > 1) Configure one of your login scripts to prompt for your OpenStack password > and > export it rather than putting it directly in a login script. > > 2) Encrypt your home directory and store your "clear text" password in a file > in your > encrypted home directory > > 3) Put your password in a file on a USB flash drive (in an encrypted file if > you want > a double layer of security) and create a wrapper script that reads you > password > from a fixed location on USB drive when you run a command. (keep the USB > drive > in a physical safe when not in use) > So I think the thing to think about is risk management. The risk of a file in a shared svn being stolen and used is a function of the number of users who can access the svn repository. Likewise, the risk of a file in your home dir and environment variables in your process space being compromised is reduced to the compromise of your own credentials and the root administrators of the machine you're on, and anybody who might get access to the disk later on if that file is left hanging around. Add backups and the risk extends to those who can read backups. So, given that, there is definitely some risk mitigation value in only ever putting your password in an exported environment variable for processes that need it. But it's not that much better than just leaving it in your home dir and changing your password routinely in case your backups get compromised. You can go through all kinds of methods to try and reduce risk more without significantly reducing convenience, including encrypted certs, gpg agents, ecryptfs, etc. etc. etc., but ultimately, you can't keep admins of a system from knowing it in the moment, and there's never going to be a way to prevent that. _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
