Jump to: navigation, search

OpenStackClient/Authentication

< OpenStackClient
Revision as of 01:34, 19 July 2013 by Dtroyer (talk | contribs) (Created page with "Authentication using OpenStackClient is performed similarly to the project CLIs starting at about the Folsom timeframe. The actual option names and environment variables are ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Authentication using OpenStackClient is performed similarly to the project CLIs starting at about the Folsom timeframe. The actual option names and environment variables are in fact the same so the same basic configuration may be used to go back-and-forth between the CLI tools.

Environment vs Option

All of the authentication information can be specified using command line global options or with environment variables. The details of converting from the option names to variable names is covered in the Human Interface Guidelines, but in short the process is simply change the dashes to underscores and make it all uppercase.

For example: The URL of the Identity endpoint can be specified with the --os-auth-url option or OS_AUTH_URL environment variable.

Note: The one difference between OSC and the project clients is (will be) OSC prefers using --os-project-name and/or --os-project-id rather than the original --os-tenant-name and friends.

FIXME(dtroyer): implement --os-project-name/-id and determine precedence and document above.


Password Flow

Password flow is commonly used for one-off, interactive and initial connections. It requires a tenant project (name or ID), username, password and Identity endpoint to be defined.

# Pick one of the following
OS_TENANT_ID=<tenant-id>                   # --os-tenant-id
OS_TENANT_NAME=<tenant-name>               # --os-tenant-name

OS_USERNAME=<username>                     # --os-username
OS_PASSWORD=<password>                     # --os-password
OS_AUTH_URL=<identity-api-endpoint>        # --os-auth-url

Notes

  • IDs vs NAMEs in Keystone: While both IDs and names are meant to be unique, IDs are immutable whereas the name can change

Token Flow

The password flow authentication requires a trip through the Identity API on each invocation of a CLI command. When performing multiple commands together (or in a script) it is more efficient to cache the authentication token and pass it to the CLI command. This is harder to do interactively with the current default PKI tokens due to their size.

OS_TOKEN=<token>                           # --os-token

The service endpoint that you'll be communicating with is normally provided by the Identity Service Catalog. The use of token flow specifically bypasses the Service Catalog so the ultimate API endpoint for the service API being called needs to be specified.

This can also be used to explicitly set the endpoint when used with password flow authentication regardless of what the service catalog has provided.

OS_ENDPOINT=<api-endpoint>                 # --os-endpoint