Justin, I think you hit upon the reason of why I think it was approved and reverted. Because it hadn't been talked about in a blueprint or a mail sent to the list (I think I'm up to date on the threads) and a patch landed means other alternatives weren't considered before pushing it through to begin with. I think we're all open to talking about how to better the auth system and make improvements. Dragon has already discussed some alternatives and suggestions on the BP page below. I think this is the right way to continue the dialog and we all can agree on a good way forward.
I'm confident we can figure it out. If I missed a conversation, my apologies. pvo From: Vishvananda Ishaya <vishvana...@gmail.com<mailto:vishvana...@gmail.com>> Date: Wed, 23 Feb 2011 18:19:41 -0800 To: Justin Santa Barbara <jus...@fathomdb.com<mailto:jus...@fathomdb.com>> Cc: <openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>> Subject: Re: [Openstack] Should the OpenStack API re-use the EC2 credentials? Hey Justin, Does it make any difference that the way the auth is (theoretically) supposed to work with the os api is that the user gets an auth token from an external auth server and then uses username / authtoken to actually contact the api? I think it is just faked out right now to use the access_key instead of doing external auth, but I think the reason it works like it does is because the plan was to switch to external auth eventually. Vish On Feb 23, 2011, at 5:56 PM, Justin Santa Barbara 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<mailto: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<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
