openstack team mailing list archive

[Chuck Thier <cthier@xxxxxxxxx>]

It seems that most of the confusion is around the conflicting terminology of
the EC2 and Rackspace apis.  I doubt either of those can really change, but
there isn't a reason that both auth methods can be supported.  As an example
this is already done in the S3 compatibility layer for Swift.

--
Chuck

On Wed, Feb 23, 2011 at 7:56 PM, Justin Santa Barbara
<justin@xxxxxxxxxxxx>wrote:

> I previously fixed OpenStack authentication so it would use the same
> credentials as EC2.  This bugfix was just reverted, because it caused
> OpenStack API users to have to enter in different credentials (sorry!), but
> primarily because it hadn't been discussed on the mailing list.  So here
> goes!
>
> Here's a blueprint:
> https://blueprints.launchpad.net/nova/+spec/authentication-consistency
>
> Here's an overview of the problem:
>
> EC2 uses an (api_key, api_secret) pair.  Post-revert, OpenStack uses the
> api_key(!) as the password, but a different value entirely as the username:
> (username, api_key).  The bugfix made it so that both APIs used the EC2
> credentials (api_key, api_secret) .  This did mean that anyone that had
> saved the 'bad' OpenStack credentials was unable to continue to use those
> credentials.  I also overlooked exporting the updated credentials in novarc
> (though a merge request was pending).
>
> I actually thought originally that this was a straight-up bug, rather than
> a design 'decision', so I should definitely have flagged it better.  Again,
> sorry to those I impacted.
>
> As things stand now, post-revert, this is probably a security flaw, because
> the EC2 API does not treat the api_key as a secret.  The EC2 API can
> (relatively) safely be run over non-SSL, because it uses signatures instead
> of passing the shared secret directly.
>
> This is also not very user-friendly.  Post-revert, an end-user must know
> whether any particular cloud tool uses the EC2 API or the OpenStack API, so
> that they can enter in the correct pair of credentials.  That doesn't seem
> like a good idea; I think there should be one set of credentials.
>
> There is some discussion about the idea of having the api_key be
> user-friendly.  I don't think it buys us anything, because the api_secret is
> still going to be un-friendly, but I have no objection as long as it is does
> in a way that does not break existing users of the EC2 API.
>
> I propose that:
>  (1) the OpenStack API and EC2 credentials should be the same as each other
> (whatever they are) for the sake of our collective sanity and
>  (2) we have to change the current configuration anyway for security
> reasons.
>  (3) We should not change the EC2 credentials, because we've shipped the
> EC2 API and our users have an expectation that we won't break them without
> good reason, so
>  (4) we must change the credentials for users of the (non-shipped)
> OpenStack API.
>
> Estimated user impact: I believe there are two people that will be
> affected, and it will take them ~1 minute each, so total impact ~2 minutes.
>
> The longer we delay fixing this, the more people we break and the bigger
> the impact.  It seems that we have no choice but to do a
> non-backwards-compatible authentication change, but I believe this is OK at
> the moment because the OpenStack API is not yet stable/released - i.e. we
> can still make fixes without worrying about backwards compatibility shims.
> We're not in "The Old New Thing" land yet :-)
>
>
>
> As an aside, I am very unhappy about the way this revert was pushed through
> by Rackspace team-members, seemingly without much consideration of
> alternatives.  Perhaps we should consider changing from needing two
> core-approves, to needing one Rackspace core-approve and one non-Rackspace
> core-approve.
>
>
> Justin
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>