Open Stack

Two people may have come into the channel and brought it to our attention
today, but this was a very recent change. I can assure you there are many
more OS API consumers out there already. It's likely that most just haven't
pulled trunk since it landed.

I think we all agree that a decision on a standard needs to be made to avoid
further pain down the road, even if it's just between us devs.

On Wed, Feb 23, 2011 at 8:38 PM, Justin Santa Barbara
<justin at fathomdb.com>wrote:

> When the authentication protocol changes, then OpenStack wrapper libraries
> will need to change - good point.  So there's even less reason to treat
> OpenStack as if it were a stable API.
>
> However, we can't expect people using those libraries to change their
> credentials - there was enough kicking and screaming when two people had to
> do that today;  when it's 200 including automated systems on big server
> farms, it'll be really painful.  So I think we should standardize on one set
> of credentials across EC2 and OpenStack asap (or decide that having
> differing sets of credentials based on the API is in fact what we want to
> do)
>
> Justin
>
>
>
>
>
> On Wed, Feb 23, 2011 at 6:19 PM, Vishvananda Ishaya <vishvananda at gmail.com
> > wrote:
>
>> 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 at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110223/1670a694/attachment.html>