[Openstack] Keyring support in openstack

Sandy Walsh sandy.walsh at RACKSPACE.COM
Tue Jul 31 09:57:42 UTC 2012


I added similar functionality to novaclient. There is a --nocache option to ignore the cache and the 'import keyring' check is just to keep it from crashing on non-supported systems. 

I key off the following: auth url + username + service name + region to prevent conflicts with other users.

Hope it helps!

-S


________________________________________
From: openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net] on behalf of Bhuvaneswaran A [bhuvan at apache.org]
Sent: Monday, July 30, 2012 5:50 PM
To: openstack at lists.launchpad.net
Subject: Re: [Openstack] Keyring support in openstack

On Mon, Jul 30, 2012 at 6:31 AM, Doug Hellmann
<doug.hellmann at dreamhost.com> wrote:

> You've already answered several of my questions on the ticket, but I still
> have some "usability" concerns.
>
> How does the keyring system support a single person logging in using
> multiple user accounts? For example, if I have an admin account and a
> "regular" user, how do I switch between them based on the operations I need
> to perform?

The password is stored in keyring, for a given user. It also support
multiple users. The password is stored against the user specified in
command line, --os-username or environment variable OS_USERNAME.

The sample content of the keyring file ~/.openstack-keyring.cfg is as follows:
[openstack]
bhuvan = dG4wN2FjxxxxxA==
test = xYwN2FjxxxxxA==

> Is there a way to disable the behavior of having a password saved to a
> keyring for a particular user, without uninstalling the python-keyring
> package (and therefore disabling keyring support for all users)?

The simplest alternative is to specify password using other mechanism,
in command line or environment variable. It's not possible to prevent
using keyring, if password is not specified in any of these 2
mechanisms. The purpose of this patch is, to prevent password prompt.

> The wiki mentions the password being saved using
> keyring.backend.UncryptedFileKeyring. Does that mean the password is saved
> in cleartext? Is the file protected in some way besides filesystem
> permissions?

As mentioned in wiki page, the password is stored in base64 format.

> The mention of one backend implies that there are others. Should we give
> users a way to choose the backend, in case they have a preference?

python-keyring also support several other backends:
  1.CryptedFileKeyring
  2. GnomeKeyring
  3. KDEKWallet
  4. OSXKeychain
  5. Win32CryptoKeyring
  6. ... and more.

The behaviour of these backends vary for each desktop. For instance,
GnomeKeyring may prompt for keyring password, once per login session.
CryptedFileKeyring may prompt for keyring password, every time. It's
as good as not using keyring.

> How does the use of the keyring affect scripting using the command line
> tool? Can a script access the keyring, or does it need to use the other
> options?

Yes. The script could be managed with any python script, using the
same methods exposed in "keyring" python module.
  -- get_password() -- to get the password for given user.
  -- set_password() -- to set the password in keyring.

> In one review comment you mention a few desktop apps that know how to
> manipulate the keyring to manage its contents. What about remote access via
> ssh, where a desktop environment is not available? Does the keyring library
> include tools for manipulating the file, or do we need to build our own? If
> so, what tools would be needed?

This was applicable for older patch, wherein we rely on
desktop/environment specific backend. With older patch, if GNOME
desktop is used, GnomeKeyring backend is used; if no desktop is used,
CryptedFileKeyring backend is used. With new patch, irrespective of
whether desktop is enabled, UncryptedFileKeyring backend is used. With
this patch, the keyring behaviour is uniform across all systems in
which we deploy openstack.

In summary, the primary goal of this patch is to reuse the password
entered in the prompt once, and prevent the user from entering the
password again. Ultimately, the password is not exposed in environment
or command line (ps). It also facilitate the automated script wherein
the "openstack" client might be used. In such case, the password is
not read from prompt, but from keyring.
--
Regards,
Bhuvaneswaran A
www.livecipher.com

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp




More information about the Openstack mailing list