sharing creds with glance cli

[Jesse Andrews]

Currently users of python-novaclient need to set variables such as

NOVA_URL=http://example.com:5000/v2.0/
NOVA_VERSION=1.1
NOVA_USERNAME=openstack
NOVA_API_KEY=yadayada
NOVA_PROJECT_ID=myproject

See: https://github.com/openstack/python-novaclient/blob/master/README.rst#id6

But as to use glance we set:

OS_AUTH_USER=<YOUR USERNAME>
OS_AUTH_KEY=<YOUR API KEY>
OS_AUTH_TENANT=<YOUR TENANT ID>
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE>
OS_AUTH_STRATEGY=keystone

See: http://glance.openstack.org/authentication.html#configuring-the-glance-client-to-use-keystone

We should use the same environment variables in (both/all?) CLIs

I propose we deprecate NOVA_* and switch to glance's style - with some caveats:

 * is AUTH_KEY the correct word? (should it be password?)
 * should AUTH_STRATEGY default to keystone
 * PROJECT_ID should be tenant (id) in both? (and should it be optional?)

[Anthony Young (sleepsonthefloor)]

Glance should support the keystone auth protocol, and use OS_AUTH_PASSORD imo. +1 one your comments in general, though I think we will have to get more specific with tenant specification. How bout:

Optional to specify one of:
    OS_AUTH_TENANT_NAME=<YOUR TENANT NAME>
    OS_AUTH_TENANT_ID=<YOUR TENANT ID>

If a tenant is not specified, the following conditions are evaluated:
* If there is only one tenant, use a token scoped to that tenant
* If there is more than one tenant, print an error message, as well as the list of possible tenants

[Jay Pipes (jaypipes)]

Hi! Yeah, totally agree that we should move to a more unified OS_* naming standard across the various dependent projects. There's a little tool in Glance that enables a quick fix for this:

jpipes@uberbox:~/repos/glance$ cat tools/nova_to_os_env.sh
# This file is intended to be sourced to convert old-style NOVA environment
# variables to new-style OS.
#
# The plan is to add this to novarc, but until that lands, it's useful to have
# this in Glance.
export OS_AUTH_USER=$NOVA_USERNAME
export OS_AUTH_KEY=$NOVA_API_KEY
export OS_AUTH_TENANT=$NOVA_PROJECT_ID
export OS_AUTH_URL=$NOVA_URL
export OS_AUTH_STRATEGY=$NOVA_AUTH_STRATEGY

But, long term, the solution is to have a single set of env variables obviously.

As for your questions, here is my opinion:

 * is AUTH_KEY the correct word? (should it be password?)

Meh, not sure :) KEY is more EC2-ish. PASS[WORD] is more Rackspace-ish. I could go either way... Perhaps do AUTH_PASSWORD and alias an AUTH_KEY as that to make things a bit more user-friendly for EC2 users? Or maybe that just adds confusion?

 * should AUTH_STRATEGY default to keystone

Actually, I think the strategy should be a description of the strategy, not the implementing project (that may implement multiple auth strategies!). Something like AUTH_STRATEGY=token would be more appropriate, right?

 * PROJECT_ID should be tenant (id) in both? (and should it be optional?)

Heh, good question :) I think that definitely PROJECT_ID should always equal TENANT_ID, yes. But the question of whether it should be optional goes back to the still-confusing default tenant issue in Keystone. I think I may have to defer to the Keystone devs on that particular decision. Has a default tenant now been removed from Keystone?

-jay

[Jay Pipes (jaypipes)]

Hi Tones,

Would this:

 If there is more than one tenant, print an error message, as well as the list of possible tenants

be a possible security hole?

Agree on your comment about OS_AUTH_PASSWORD and TENANT_NAME and TENANT_ID...

What did you mean by "glance should support the keystone auth protocol", though? I completely agree we should, but I'm not sure what we aren't currently supporting? Could you elaborate?

Thanks!
-jay

[Anthony Young (sleepsonthefloor)]

Hey Jay,

If the user does not already have a token, she can retrieve it via the auth protocol:

https://lists.launchpad.net/openstack/msg04211.html

Part of the this protocol involves using an 'unscoped' token to retrieve a list of tenants for that user (not a global tenant list, which would be a security hole).

Using this, a user can (for example) log into horizon with a username and password (vs. specifying a long key). novaclient also implements this protocol.

Correct me if I'm wrong, but my understanding is that the user must already have a token before using the glance client. This is what we do in devstack:

glance add -A $SERVICE_TOKEN ...

[Jason Cannavale (jcannava)]

+1 on the concept of moving everything to OS_*. Does this change/bug include fixing nova-manage to be able to output the relevant information to novarc with the new variables?

Other comments:
 - Listing tenants shouldn't be a security hole, only if you were to lists the users/passwords underneath do you open a problem..IMHO
- Agree that strategy should not be based on the project that implements it, in the current case token = keystone, allows for others as time goes on.
- IMO it should be OS_AUTH_PASSWORD since that's what actually goes there... KEY seems to be confusing looking at past questions...

Jason

[Anthony Young (sleepsonthefloor)]

Actually, novaclient does not implement this protocol atm...

[Jesse Andrews (anotherjesse)]

There are two flows:

* You can either specify ids/names/passwords and the CLI will communicate with keystone to get a token
* You can specify the token (having already been through the keystone dance to retrieve it)

The second is useful when you have to do many calls (in a scripted fashion) or also when used via an API.

[Jay Pipes (jaypipes)]

Tones,

Got it, thanks for the followup elaboration. And yes, you are absolutely correct.

So, I will change the existing bug about removing the -A option in the client to instead *adding* the ability to instead use a user/password and have the client interact with Keystone and grab a token for the session.

Does that meet with you expectations about the Glance client?

-jay

[Jay Pipes (jaypipes)]

For reference: https://bugs.launchpad.net/glance/+bug/853933

[Jesse Andrews (anotherjesse)]

proposal for id/name/password flow:

* require specification of user id or name
* until the time where keystone support of default tenant is well defined require specification of tenant id or name
* require keystone endpoint

QUESTIONS:

* for auth strategies - do we support multiple at this point? If not should we remain mute on this until we know more?
* if the proposed requirements are ok, then we can argue OS_USER_ID vs OS_AUTH_USER_ID vs OS_AUTH_USER... Do we need the word AUTH?

ASSUMPTIONS:

* both glance and nova would updated their docs to reflect the new env variables - but would continue supporting during ESSEX their deprecated variables. (pulling from them if new-style variables aren't set)

NOTE:

Keystone IDs vs NAMEs

While both ids and names are meant to be unique, IDs are immutable whereas the name can change

[Jesse Andrews (anotherjesse)]

Also perhaps this should become a wiki page while we are fleshing it out?

Seems like there will be several bugs created from this (python-novaclient doesn't have blueprints enabled so I filed this as a bug originally)

[Anthony Young (sleepsonthefloor)]

Jay, yes that makes sense, and Jesse thanks for adding the detailed specs for u/p auth. I'm ok with making tenant specification (either by name or id) required for now, thus letting CLIs bypass the 'unscoped token' portion of the login protocol for now. We can revisit that separately if it becomes a stumbling block for users.

[Jay Pipes (jaypipes)]

I went ahead and updated the description of bug 853933 to reflect the discussion here... please double-check the changes if you could.

Jesse, I agree with all your proposal points above

re: your questions:

Glance already supports multiple strategies -- though only one strategy (token) is actually included in the Glance distribution. So, I think the answer is "support token auth as #1 priority, making the code as pluggable as possible"...

I could definitely go with just OS_USER_ID instead of having AUTH in the name... no problems there.

-jay

[Jesse Andrews (anotherjesse)]

I've started a page on the wiki: http://wiki.openstack.org/CLIAuth

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/3493
Committed: http://github.com/openstack-dev/devstack/commit/10670d1bad6b4afd3dce9af61d22c8cd5eeded59
Submitter: Jenkins
Branch: master

commit 10670d1bad6b4afd3dce9af61d22c8cd5eeded59
Author: Dean Troyer <email address hidden>
Date: Tue Jan 24 11:26:15 2012 -0600

    Add support for OS_* environment vars

    Add the OS_* env variables to mirror the NOVA_* vars; example:
    setting OS_USERNAME will override NOVA_USERNAME in the clients and
    tools, but if left unset it defaults to NOVA_USERNAME.

    Adds exercises/client-env.sh to test operation of command-line
    clients with only the OS_* variables set

    Addresses bug 897304, http://wiki.openstack.org/CLIAuth

    Change-Id: I72450153541072fe8026a82748cfcd1cf5ed31d8

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/3677
Committed: http://github.com/openstack/python-novaclient/commit/3a3f2b4ff871e3ac61ca2a0b95903c54be9f7a22
Submitter: Jenkins
Branch: master

commit 3a3f2b4ff871e3ac61ca2a0b95903c54be9f7a22
Author: Dean Troyer <email address hidden>
Date: Thu Feb 2 10:32:30 2012 -0600

    Blueprint cli-auth: common cli args

    Depricate --apikey, --projectid, --url (though still present for
    compatibility). Fully support OS_* env vars per
    http://wiki.openstack.org/CLIAuth Password Flow.

    Fixes lp897304

    Change-Id: I655631194ed62133c24f30c9114e6fdc0fa77636