CLIAuth

= 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= OS_AUTH_KEY= OS_AUTH_TENANT= OS_AUTH_URL= 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 ST_USER=  # --user ST_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= # --os_auth_url OS_PASSWORD= # --os_password OS_USERNAME= # --os_username

OS_TENANT_ID= # --os_tenant_id OS_TENANT_NAME= # --os_tenant_name
 * 1) allow one of the following:

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= # --os_auth_url OS_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=   # 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