On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak <[email protected]> wrote:
> > On 16/05/17 01:09, Lance Bragstad wrote: > > > > On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <[email protected]> > 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/ > > > > 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/ > > Tangentially related to this (because my reasons are different), on our > cloud I'm actually working on something like this, but under the hood all > I'm doing is creating a user with a generated password and enforcing a > username convention. I ask them for a name and what roles they want for the > user and I spit out: > username: "service_user_for_web_app_1@<project_id>" > password: "<some_generated_password>" > > l'lI always generate/regenerate that password for them, and once shown to > them once, they can't ever see it again since the plaintext secret is never > stored. Sure I can't stop them from logging into the dashboard with that > user or changing the password themselves directly, but that's impossible to > avoid without being able to set a fine grained role that this user can't > access password changing stuff. Ultimately though the user changing their > password isn't a problem, and someone else can always delete the user or > regen a password. > > The only reason I'm even working on this is because we currently only > allow emails as username on our cloud through our management service. We > did that to avoid unique name constraints in a single domain, and to allow > us easier ways to do password reset tokens and inviting others to join your > project and set their own user password. But... our customers also need a > way to create service users with set roles. By enforcing the name@<project_id> > convention I get around the username unique constraint but let them give > useful descriptive names to these users. > > Also worth noting that we have some custom policy files to allow some very > limited fine grained access control with roles. All I really want/need is > better/dynamic policies and honestly users are all the API keys I can ever > see being needed. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
