One set of credentials across EC2 and OpenStack APIs

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.
          Pluses:
                     This is the simplest design, and would be more convenient for users with mixed toolsets.
          Minuses:
                     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.)