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 <jus...@fathomdb.com>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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp