On 16/05/17 14:00, Adrian Turjak wrote: > > On 16/05/17 13:29, Lance Bragstad wrote: >> >> >> On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak >> <adri...@catalyst.net.nz <mailto:adri...@catalyst.net.nz>> wrote: >> >> >> On 16/05/17 01:09, Lance Bragstad wrote: >>> >>> >>> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor >>> <mord...@inaugust.com <mailto:mord...@inaugust.com>> wrote: >>> >>> On 05/11/2017 02:32 PM, Lance Bragstad wrote: >>> >>> Hey all, >>> >>> One of the Baremetal/VM sessions at the summit focused >>> on what we need >>> to do to make OpenStack more consumable for application >>> developers [0]. >>> As a group we recognized the need for application >>> specific passwords or >>> API keys and nearly everyone (above 85% is my best >>> guess) in the session >>> thought it was an important thing to pursue. The API >>> key/application-specific password specification is up >>> for review [1]. >>> >>> The problem is that with all the recent churn in the >>> keystone project, >>> we don't really have the capacity to commit to this for >>> the cycle. As a >>> project, we're still working through what we've >>> committed to for Pike >>> before the OSIC fallout. It was suggested that we reach >>> out to the PWG >>> to see if this is something we can get some help on from >>> a keystone >>> development perspective. Let's use this thread to see if >>> there is anyway >>> we can better enable the community through API >>> keys/application-specific >>> passwords by seeing if anyone can contribute resources >>> to this effort. >>> >>> >>> In the session, I signed up to help get the spec across the >>> finish line. I'm also going to do my best to write up >>> something resembling a user story so that we're all on the >>> same page about what this is, what it isn't and what comes next. >>> >>> >>> Thanks Monty. If you have questions about the current proposal, >>> Ron might be lingering in IRC (rderose). David (dstanek) was >>> also documenting his perspective in another spec [0]. >>> >>> >>> [0] https://review.openstack.org/#/c/440593/ >>> <https://review.openstack.org/#/c/440593/> >>> >>> >> >> Based on the specs that are currently up in Keystone-specs, I >> would highly recommend not doing this per user. >> >> The scenario I imagine is you have a sysadmin at a company who >> created a ton of these for various jobs and then leaves. The >> company then needs to keep his user account around, or create >> tons of new API keys, and then disable his user once all the >> scripts he had keys for are replaced. Or more often then not, >> disable his user and then cry as everything breaks and no one >> really knows why or no one fully documented it all, or didn't >> read the docs. Keeping them per project and unrelated to the user >> makes more sense, as then someone else on your team can >> regenerate the secrets for the specific Keys as they want. Sure >> we can advise them to use generic user accounts within which to >> create these API keys but that implies password sharing which is bad. >> >> >> That said, I'm curious why we would make these as a thing >> separate to users. In reality, if you can create users, you can >> create API specific users. Would this be a different >> authentication mechanism? Why? Why not just continue the work on >> better access control and let people create users for this. >> Because lets be honest, isn't a user already an API key? The >> issue (and the Ron's spec mentions this) is a user having too >> much access, how would this fix that when the issue is that we >> don't have fine grained policy in the first place? How does a new >> auth mechanism fix that? Both specs mention roles so I assume it >> really doesn't. If we had fine grained policy we could just >> create users specific to a service with only the roles it needs, >> and the same problem is solved without any special API, new auth, >> or different 'user-lite' object model. It feels like this is >> trying to solve an issue that is better solved by fixing the >> existing problems. >> >> I like the idea behind these specs, but... I'm curious what >> exactly they are trying to solve. Not to mention if you wanted to >> automate anything larger such as creating sub-projects and >> setting up a basic network for each new developer to get access >> to your team, this wouldn't work unless you could have your API >> key inherit to subprojects or something more complex, at which >> point they may as well be users. Users already work for all of >> this, why reinvent the wheel when really the issue isn't the >> wheel itself, but the steering mechanism (access control/policy >> in this case)? >> >> >> All valid points, but IMO the discussions around API keys didn't set >> out to fix deep-rooted issues with policy. We have several specs in >> flights across projects to help mitigate the real issues with policy >> [0] [1] [2] [3] [4]. >> >> I see an API key implementation as something that provides a cleaner >> fit and finish once we've addressed the policy bits. It's also a >> familiar concept for application developers, which was the use case >> the session was targeting. >> >> I probably should have laid out the related policy work before >> jumping into API keys. We've already committed a bunch of keystone >> resource to policy improvements this cycle, but I'm hoping we can >> work API keys and policy improvements in parallel. >> >> [0] https://review.openstack.org/#/c/460344/ >> [1] https://review.openstack.org/#/c/462733/ >> [2] https://review.openstack.org/#/c/464763/ >> [3] https://review.openstack.org/#/c/433037/ >> [4] https://review.openstack.org/#/c/427872/ >> > I'm well aware of the policy work, and it is fantastic to see it > progressing! I can't wait to actually be able to play with that stuff! > We've been painstakingly tweaking the json policy files which is a > giant mess. > > I'm just concerned that this feels like a feature we don't really need > when really it's just a slight variant of a user with a new auth model > (that is really just another flavour of username/password). The sole > reason most of the other cloud services have API keys is because a > user can't talk to the API directly. OpenStack does not have that > problem, users are API keys. So I think what we really need to > consider is what exact benefit does API keys actually give us that > won't be solved with users and better policy? > > From my look at the specs the only feature difference compared to > users is optional expiry of the API keys. Why make something entirely > different for just that one feature when, as David says in his spec, > there is debate if that feature is even a good idea. > > As an application developer, I don't see why I can't just create a > user and limit the roles. I feel as if this is better addressed with > documentation because it almost sounds like people are asking for > something that already exists, but just doesn't have as nice an API as > they would like. Another option, make a better API in Keystone for > user creation/management alongside the old one? That's pretty much > what we did, except we wrote a service to act as a proxy/wrapper > around Keystone for some customer actions. >
If expiry is the killer feature, why no just add it to users? Temporary user accounts could solve that, and probably be useful beyond the scope of just API keys.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev