Latest revision as of 23:30, 17 February 2013

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

@@ Line 1: / Line 1: @@
-__NOTOC__
 = CLI Auth =
@@ Line 7: / Line 7: @@
 STATUS: '''DRAFT'''
+This will be absorbed into [[UnifiedCLI]] as that gets developed.
 Issues:
@@ Line 43: / Line 45: @@
 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:
+<pre><nowiki>
+ST_AUTH=<auth token URL>   # --auth
+ST_USER=<username>   # --user
+ST_KEY=<auth key>   # --key
+</nowiki></pre>
 == Goals ==
@@ Line 58: / Line 70: @@
 * 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
+* for essex keystone will support default tenant, a client can override the default tenant by specifying it
 * require keystone endpoint
 <pre><nowiki>
-OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE>
+require:
-OS_PASSWORD=<YOUR PASSWORD>
+OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url
+OS_PASSWORD=<YOUR PASSWORD> # --os_password
+OS_USERNAME=<YOUR USER NAME> # --os_username
-# require: one of the following
+# allow one of the following:
-OS_USER_ID=<YOUR USER ID>
+OS_TENANT_ID=<YOUR TENANT ID> # --os_tenant_id
-OS_USER_NAME=<YOUR USER NAME>
+OS_TENANT_NAME=<YOUR TENANT NAME> # --os_tenant_name
-# require one of the following:
-OS_TENANT_ID=<YOUR TENANT ID>
-OS_TENANT_NAME=<YOUR TENANT ID>
 </nowiki></pre>
@@ Line 87: / Line 97: @@
 <pre><nowiki>
-OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE>
+OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url
-OS_TOKEN=<YOUR TOKEN>
+OS_TOKEN=<YOUR TOKEN> # --os_token
 </nowiki></pre>
@@ Line 96: / Line 106: @@
 * 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.
+<pre><nowiki>
+OS_REGION_NAME=<region>    # Glance
+OS_AUTH_STRATEGY=noauth|keystone   # Glance
+</nowiki></pre>
+== 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

Difference between revisions of "CLIAuth"