search

termie / nova-migration-demo

Nova is a cloud computing fabric controller (the main part of an IaaS system). It is written in Python.
http://openstack.org/projects/compute/
Apache License 2.0
2 stars 0 forks source link

OpenStack and EC2 APIs use different usernames and passwords #553

Open termie opened 13 years ago

termie commented 13 years ago

The OpenStack and EC2 APIs don't use the same username & password.

This is obviously untenable: it leads to a world where an end user would need to know which API their front-end application was using behind the scenes.

Imported from Launchpad using lp2gh.

termie commented 13 years ago

(by blamar) I disagree with the unsaid premise of the bug which seems to say that the OpenStack and EC2 APIs should be completely interchangeable. IMO each API must be given the freedom to authenticate users how they see fit, set up their own authorization rules using OpenStack libraries, and otherwise be able to operate with complete autonomy. I see this flexibility as a key differentiator allowing OpenStack to host any number of different APIs while still providing a wide variety of features.

termie commented 13 years ago

(by justin-fathomdb) Well, as long as you understand that by disagreeing you're personally signing up for 10 years of front-line support, on the helpdesk whose sole responsibility is the question "why can't I log in to my cloud?"

Here's the schedule so far:

2011 - 2020 Monday 1st shift: BL Monday 2nd shift: BL Monday 3rd shift: BL Tuesday 1st shift: BL Tuesday 2nd shift: BL ...

:-)

termie commented 13 years ago

(by ewanmellor) Justin didn't say that the OpenStack and EC2 APIs should be completely interchangeable -- he said that they should use the same username and password.

I agree with Justin. We're going to have a world where some tools are built using the EC2 API, and some using the OpenStack API, and both will be used in parallel in the one cloud, and which is which is going to be completely invisible to the end user. We'd be crazy to have two independent passwords.

"So, here are your two usernames and two passwords. When you log into self-service.acme.com, then use this password, and when you log into billing-records.acme.com, use this other password. And we're upgrading self-service.acme.com at the end of the year and they've switched to the OpenStack API, so you'll switch passwords at that point. Oh, and it's going to be an incremental upgrade, so for a couple of weeks the GSLB might direct you either to a version 1.0 node or a version 2.0 node. You'll figure that out. Have fun!"

termie commented 13 years ago

(by vishvananda) This isn't strictly true. The ec2 credentails are an access and secret key, which is a bit different from a username and password. I don't think we can think of them as completely interchangable. In many auth systems, you use a username and password to generate a token which has a key and a secret.

Vish

On Mar 10, 2011, at 2:19 PM, justinsb wrote:

Public bug reported:

The OpenStack and EC2 APIs don't use the same username & password.

This is obviously untenable: it leads to a world where an end user would need to know which API their front-end application was using behind the scenes.

\ Affects: nova Importance: Undecided Status: New

You received this bug notification because you are a member of Nova Bug Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/732907

Title: OpenStack and EC2 APIs use different usernames and passwords

Status in OpenStack Compute (Nova): New

Bug description: The OpenStack and EC2 APIs don't use the same username & password.

This is obviously untenable: it leads to a world where an end user would need to know which API their front-end application was using behind the scenes.

termie commented 13 years ago

(by justin-fathomdb) You signing up to join Brian on the schedule there Vish? :-)

I think these nuances of access key / secret key vs username / password are a bit lost on me. For both, you have an identifier and a secret. At the moment of authentication, I need to demonstrate that I know the password. I can either do this by telling you my secret over a secure link, or we can both do a crypto calculation that proves I have the same secret. Whether I exchange this for a token or not is just an implementation detail, mostly to support federation. I don't see why we can't use the same credentials irrespective of these details, just like I don't have to switch passwords when I'm using HTTP basic auth vs HTTP digest. What am I missing?

I think Ewan nailed the explanation - it's a terrible user experience. In the absence of a solid technical reason, I just don't understand why we would want to do that.

termie commented 13 years ago

(by ewanmellor) Yes, I know that the EC2 API calls them "access key ID" and "secret access key", but this doesn't make it a token exchange scheme just because they are named differently. It's a fixed public identifier plus a fixed secret thing, aka a username and password.

termie commented 13 years ago

(by ewanmellor) I think the point is, Amazon have a username and password, but it's in an authentication system that's completely distinct from the EC2 system. With your Amazon password, you can log in to their auth system and obtain your "access key ID" and "secret access key", but those are just a username/password pair with fancy names.

Presumably, Amazon felt the need to separate your API access from everything else so that you couldn't buy books with someone's EC2 credentials. This doesn't apply to us for two reasons: 1) we don't sell books and 2) we don't have other systems that you can log into.

We can simplify the distinction between "password" and "secret access key" because our password is only useful for one thing.

termie commented 13 years ago

(by eday) On Fri, Mar 11, 2011 at 09:35:22AM -0000, justinsb wrote:

I think Ewan nailed the explanation - it's a terrible user experience. In the absence of a solid technical reason, I just don't understand why we would want to do that.

The main reason I'm aware is so you can generate multiple access keys/secrets for the same account (tied to a single user/pass). This allows you to hand out access keys to various places (management websites, tools, etc.) and revoke those access keys if needed should something happen to just a single tool. This doesn't require changing your password everywhere. The same thing can be accomplished with proper user management within a single account, it's just another way of looking at the same problem.

If we go with token based auth, this may be a bit more difficult since OS can lookup the token, but EC2 would not use the token (it needs key and secret for signature). So some clients would be need to use ec2 style and others would simply have a token. All things to discuss at the summit probably as we figure out the auth plan.

-Eric