Jump to: navigation, search

CLIAuth

Revision as of 07:07, 18 December 2011 by Anotherjesse (talk)

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
  • 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> # --auth_url
OS_PASSWORD=<YOUR PASSWORD> # --password
OS_USERNAME=<YOUR USER NAME> # --username

# allow one of the following:
OS_TENANT_ID=<YOUR TENANT ID> # --tenant_id
OS_TENANT_NAME=<YOUR TENANT NAME> # --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> # --auth_url
OS_TOKEN=<YOUR TOKEN> # --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)

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 with the OS_ prefix removed. For example: OS_AUTH_URL can be specified with the --auth_url flag.

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:

  • auth_url
  • password
  • username # or user.id
  • tenant_id # or tenant.id
  • tenant_name # or tenant.id