openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

Hi Josh - I didn't think your Python API bindings were in particularly
widespread use yet because they were so new.  But I'm a big fan and love how
they are moving so quickly.  I think I hit some bugs in them one day and
then when I pulled the next day you'd fixed them all.  Perhaps there was
some meiosis in my estimate of the auth-change impact ;-) ... no offence
intended towards your work on the bindings.

I'd love to see your project as part of nova, so that we can use it as our
reference implementation of the OpenStack API and keep an official binding
in lock-step with developments to the API.  Any chance of that happening?

Justin


On Wed, Feb 23, 2011 at 6:54 PM, Josh Kearney <josh@xxxxxxx> wrote:

> 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@xxxxxxxxxxxx
> > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>