bin/glance should have --user/--password auth protocol negotiation

[Jay Pipes]

The --auth-token/-A option to bin/glance is good for scripted activities, but it requires the user to have already queried Keystone for a usable token for communication. The glance client should support --user/--password options as well (exclusive option to --auth-token) and communicate with the Identity server for a token to use in an operation.

For reference discussion, please see bug 897304

[Aaron Lee (aaron-lee)]

This involves adding a clear way to specify the user and key, then get the token from keystone. In addition to striping the argument form bin/glance there are several functional tests in test_shared_images.py that execute this command using the --auth-token argument.

[Jesse Andrews (anotherjesse)]

While I agree user/tenant/password is a primary way of interacting with openstack, advance users will want to use the token.

I can put a token into a situation (vm or otherwise) that I don't want want to share a password

[Jay Pipes (jaypipes)]

Hey Jesse, could you elaborate on the above, please? I'm not sure I quite understand the use case... are you saying you want to keep functionality around that enables a user to set up a long-lived auth token in Keystone and supply that manually to Glance? That sounds like a pretty big security hole to me, but perhaps I'm not quite understanding your request...

-jay

[Kevin L. Mitchell (klmitch)]

My 2 cents: We will always need for the Client class to take the auth token as an optional argument; this is the way we can allow nova to access glance with the user's credentials. If we need this here, then it seems to me that it will also be useful from the command line; instead of getting an auth token each time we try to use it, we have the capability of getting the auth token once and using it over and over, which could be handy in some sort of automated processing. As an example, consider an admin that wants to write a shell script that scans through glance images, examining the metadata of each for an expiration timestamp, and deletes those images that have expired. Without --auth-token, Keystone will be hit potentially 2N times, whereas with it, we can potentially hit Keystone once and reuse those credentials over and over. (And yes, if I were writing this, I'd write it using the Python API; but I don't think we want to require admins to learn Python just to build fairly simple management tools.)

Long-term, I'd like to see the client authentication plugin that hits Keystone provide two different means of specifying credentials: the current user/tenant/password scheme, and an auth token scheme. My full plugin architecture idea would provide command line arguments for these; the environment variables are kind of a stop-gap that Rick used for now.

[Jay Pipes (jaypipes)]

OK, we'll revisit this after E1...

[Eoghan Glynn (eglynn)]

Just to clarify, presumably we need to go slightly beyond the --user/--password CLI switches mentioned in the bug summary and also add optional --tenant-id|--tenant-name switches?

(Going on the discussion in bug 897304 and http://wiki.openstack.org/CLIAuth)

[Jay Pipes (jaypipes)]

Yes, Eoghan, I think that makes the most sense.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/3272

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/3272
Committed: http://github.com/openstack/glance/commit/6cac288a87d0eba448394ac39981bf9f63238125
Submitter: Jenkins
Branch: master

commit 6cac288a87d0eba448394ac39981bf9f63238125
Author: Eoghan Glynn <email address hidden>
Date: Fri Jan 20 20:27:02 2012 +0000

    More flexible specification of auth credentials.

    Fixes bug 853933

    Add new --username|--password|--tenant|--auth_url|--auth_strategy
    switches to bin/glance to allow the username, password, tenant name,
    and authentication URL & strategy be specified on the command line.

    Avoid needlessly falling back to keystone v2 auth after a successful:

      GET /v1.0/tokens

    returns with the X-Image-Management-Url or X-Glance header set,
    as opposed to X-Server-Management-Url.

    Extend the keystone functional test support to ensure that the URL
    returned by keystone via the X-*-Url header contains the appropriate
    dynamically allocated port for the glance API service.

    Ensure the underlying $OS_* environment variables do not leak into the
    TestPrivateImagesCli functional tests, also explicitly exercise both
    noauth and keystone strategies.

    Change-Id: Iee8bf3745d65a9c57a9da803d5cf9ae5f343a159