One set of credentials across EC2 and OpenStack APIs

Registered by justinsb

Currently there are different credentials for the OpenStack API and the EC2 API. An end-user must therefore know whether an application they are using uses the OpenStack API or the EC2 API under the hood, and must choose the correct set of credentials. This should be fixed: there should be one set of credentials, and it should be the EC2 credentials to minimize impact.

Blueprint information

Needs approval
Series goal:
Proposed for cactus
Milestone target:
Completed by
Vish Ishaya

Related branches



Justin SB wrote: ---------------------------------------------------------------------------------------
Monsyne Dragon has contributed some interesting notes below. The core issue is that having 2 sets of API credentials is a bad user experience, and the current implementation contains a likely security flaw which we should resolve. Despite our differing thought processes, we agree that there should be one set of credentials.

Monsyne Dragon wrote: ---------------------------------------------------------------------------------------

Notes on auth credentials in nova:

The issue to be resolved by this blueprint is a design oddity in the Nova code, in the way it stores auth credentials for a user, thru the ec2, vs openstack api's. Currently, nova stores three pieces of data for a user: username, access_key and the secret_key.

Authentication with the EC2 api uses the access_key to identify the user, and uses the secret_key as the passcode, by using it to calculate a cryptographic signature for the request.

Authentication with the openstack api uses the username to identify the user, and uses the access_key as the passcode, in a traditional username/password style auth over a ssl request.

The oddity is that nova is using the same value (access_key) as the user identifier in ec2 and the password in openstack-api.

Here are four possible fixes for this situation:

Design 1:
  Use the same username/password pair for both openstack and ec2 api's.
                     This is the simplest design, and would be more convenient for users with mixed toolsets.
                     This would require existing credentials for at least one api (which one would depend on how the migration was written) to change for all users.
         Possible impediments:
                    I1) The ec2 api_key has usually been a uuid-type hex string, the openstack username is usually a human readable login name. These differences might be unimportant, however there could be differing requirements, either internal (formatting) or external ("must be human-memorable" vs "must be <large number> of bytes for security", or differing business requirements) which prevent the same value from being used for each.
                   I2) A similar problem might exist for the access_key and secret_key. The secret_key is used to compute a cryptographic signature in the ec2 api. It may need to be generated as part of a public/private keypair, or have other cryptographic requirements that the openstack-api access_key (basically used as an opaque string) might not meet, and may make it awkward to use for an access_key.

Design 2:
  Use separate user identifiers for each api, but make them more sensibly use the secret_key as the 'passcode' for both api's.
  Pluses: Doable if impediment #1 above prevents designs 1&3 from being used.
  Minuses: Would still require changing credentials for 1 api on implementation.
  Possible impediments: Same as I2 above.

Design 3:
  Use separate passcodes for each api, but make them use the same user identifier for both api's. For example: access_key becomes openstack_key, and username is used as both the os-username and ec2-api-key.
  Pluses: Doable if impediment #2 above prevents design 1&2 from being used.
  Minuses: Would still require changing credentials for 1 api on implementation.
  Possible impediments: Same as I1 above.

Design 4:
  Completely separate ec2 and openstack user credentials in nova. Either have 4 columns on user (ec2_access_key, ec2_secret_key, os_username, and os_api_key) or move credentials to a separate table w/ a 1-many rel to user.
  Pluses: would not require changing api credentials on implementation (the migration could copy access_key to the new column, or db_row, as a migration step, then the ec2_access_key and os_api_key would be unrelated thereafter) NOt blocked by impediments 1 or 2.
  Minuses: more complex solution. not as convenient ot users in the long run.
  Possible impediments: none that I know of at the moment.

(Of these I'd recommend design #1 if we can do it, #4 if we can't -mdragon.)


Work Items

This blueprint contains Public information 
Everyone can see this information.