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

This will be absorbed into UnifiedCLI as that gets developed.

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.

And to configure Swift we set:

ST_AUTH=<auth token URL>   # --auth
ST_USER=<username>   # --user
ST_KEY=<auth key>   # --key

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
for essex keystone will support default tenant, a client can override the default tenant by specifying it
require keystone endpoint

require:
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url
OS_PASSWORD=<YOUR PASSWORD> # --os_password
OS_USERNAME=<YOUR USER NAME> # --os_username

# allow one of the following:
OS_TENANT_ID=<YOUR TENANT ID> # --os_tenant_id
OS_TENANT_NAME=<YOUR TENANT NAME> # --os_tenant_name

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_auth_url
OS_TOKEN=<YOUR TOKEN> # --os_token

notes

If user sets variables for both password and token flows, the token should take preference
perhaps this flow only works if you also know the endpoint of the glance/nova service (eg, you need to supply both the token & endpont)

Additional Variables

Some clients have additional variables to control authentication behaviour. Where they exist these should follow the same convention.

OS_REGION_NAME=<region>    # Glance
OS_AUTH_STRATEGY=noauth|keystone   # Glance

Setting parameters via flag

Any environment variable parameter can alternatively be specified via flag. This flag should be the same as a downcase version of the environment variable. For example: OS_AUTH_URL can be specified with the --os_auth_url flag. This will hopefully lessen confusion between the values used for authentication and the values that a given command might require, e.g. creating a user in Keystone required both an authentication username as well as the name of the user to be created.

Library Implementations

Python implementations should internally use names that are similar to CLI variables, so that all projects refer to these concepts in the same way. For example:

os_auth_url
os_password
os_username # or os_user.id
os_tenant_id # or os_tenant.id
os_tenant_name # or os_tenant.name

Wiki

Page

User