Revision as of 20:17, 28 November 2011

CLI Auth

Using OpenStack from CLI is currently different for each project. Let's fix that!

Originally started as a bug. This page addresses how openstack users will interact with glance/nova (and other) CLI tools for the ESSEX release.

STATUS: DRAFT

Issues:

examples are for environment variables, should cover library api as well?
standardize method for generating a token / getting endpoint list (keystone client?)
integration with swift client?

State of Diablo

To configure python-novaclient you use environment variables:

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

Whereas to configure 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

Glance also provides a script tools/nova_to_os_env.sh which helps convert these nova users interact with glance.

Thus, at this time there are multiple and competing techniques for auth being used in OS projects. For essex, a consistent and unified strategy should be designed and implemented across the CLIs.

Goals

Support two flows:

PASSWORD FLOW: User can either specify ids/names/passwords and the CLI will communicate with keystone to get a token
TOKEN FLOW: User can specify the token (having already been through the keystone dance to retrieve it)

The password flow is useful when the client have to do many calls (in a scripted fashion) or also when used via an API.

Both glance and nova cli would update their code & 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)

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

OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE>
OS_PASSWORD=<YOUR PASSWORD>

# require: one of the following
OS_USER_ID=<YOUR USER ID>
OS_USER_NAME=<YOUR USER NAME>

# require one of the following:
OS_TENANT_ID=<YOUR TENANT ID>
OS_TENANT_NAME=<YOUR TENANT ID>

notes

IDs vs NAMEs in Keystone: While both ids and names are meant to be unique, IDs are immutable whereas the name can change
tenant is required until default tenants / unscoped tokens / ... is further defined in keystone

Token Flow

If a client is going to make multiple calls, caching it locally is more efficient for both the user and service. (See discussion in glance bug)

OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE>
OS_TOKEN=<YOUR TOKEN>