Jump to: navigation, search

Difference between revisions of "CLIAuth"

Line 43: Line 43:
  
 
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.
 
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 ==
 
== Goals ==
Line 64: Line 74:
 
<pre><nowiki>
 
<pre><nowiki>
 
require:
 
require:
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --auth_url
+
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url
OS_PASSWORD=<YOUR PASSWORD> # --password
+
OS_PASSWORD=<YOUR PASSWORD> # --os_password
OS_USERNAME=<YOUR USER NAME> # --username
+
OS_USERNAME=<YOUR USER NAME> # --os_username
  
 
# allow one of the following:
 
# allow one of the following:
OS_TENANT_ID=<YOUR TENANT ID> # --tenant_id
+
OS_TENANT_ID=<YOUR TENANT ID> # --os_tenant_id
OS_TENANT_NAME=<YOUR TENANT NAME> # --tenant_name
+
OS_TENANT_NAME=<YOUR TENANT NAME> # --os_tenant_name
 
</nowiki></pre>
 
</nowiki></pre>
  
Line 85: Line 95:
  
 
<pre><nowiki>
 
<pre><nowiki>
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --auth_url
+
OS_AUTH_URL=<THIS SHOULD POINT TO KEYSTONE> # --os_auth_url
OS_TOKEN=<YOUR TOKEN> # --token
+
OS_TOKEN=<YOUR TOKEN> # --os_token
 
</nowiki></pre>
 
</nowiki></pre>
  
Line 96: Line 106:
  
 
== Setting parameters via flag ==
 
== 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.
+
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 =
 
= 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:
 
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
+
* os_auth_url
* password
+
* os_password
* username # or user.id
+
* os_username # or os_user.id
* tenant_id # or tenant.id
+
* os_tenant_id # or os_tenant.id
* tenant_name # or tenant.id
+
* os_tenant_name # or os_tenant.id

Revision as of 22:29, 13 March 2012

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.

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)

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.id