On Tue, May 16, 2017 at 8:54 AM, Monty Taylor <mord...@inaugust.com> wrote:
> On 05/16/2017 05:39 AM, Sean Dague wrote: > >> On 05/15/2017 10:00 PM, 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: >>>> >>> <snip> >> >>> 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? >>> >> >> The benefits of API key are if it's the same across all deployments, so >> your applications can depend on it working. That means the application >> has to be able to: >> >> 1. provision an API Key with normal user credentials >> 2. set/reduce permissions with that with those same user credentials >> 3. operate with those credentials at the project level (so that when you >> leave, someone else in your dept can take over) >> 4. have all it's resources built in the same project that you are in, so >> API Key created resources could interact with manually created resources. >> 5. revoke at any time (and possibly bake in an expiration to begin with) >> >> #1 means these can't just be users. By the user survey 30% are using >> LDAP/AD, which means the authority to create a user isn't even cloud >> admin level, it's company AD level. It may literally be impossible to do. >> >> #2 means permissions can't be done with roles. Normal users can't create >> roles, and roles don't properly express permissions inherent in them >> either. Even if users started to be able to create roles, that would >> mean an incredible role explosion. >> >> #2 also means this interface can't use policy. Policy an internal >> structure for operators setting allow points, and is a DSL that we >> *really* don't want to make everyone learn every bit of. >> >> #4 means this can't be done with special projects where users could >> create other users using the existing SQL split backend setup in >> keystone (even if they had AD). This is complicated to setup in the >> first place, but if API Key created servers aren't able to get to the >> network that was manually setup in a different tenant, the usefulness is >> limited. >> >> >> This is why the proposal out of the room going forward was some concrete >> steps: >> >> 1) Make a new top level construct of an APPKey that exists within a >> project, that all users can create in projects they are members of. >> >> This immediately solves #1. And even inheriting Member role becomes >> useful because of the revoke facility. There are now a set of >> credentials that are ephemeral enough to back into images / scripts, >> that aren't also getting into your health records or direct deposit at >> your company. >> >> 2) Provide a mechanism to reduce what these APPKeys can do. Policy & >> Roles is actually the wrong approach, those are operator constructs. API >> consuming things understand operations in terms of ("Region1", >> "compute", "/servers", "GET"). Something along those lines would be >> provided as the way to describe permissions from a user. >> >> The complaint is this is a second way of describing permissions. It is. >> But the alternative to teach our entire user base about policy name >> points is ... far less appealing. We should be tailoring this to the >> audience we want to consume it. >> >> >> Yes, these are 2 distinct steps, but I think it's disengenous to say the >> first step is pointless until the second one is done. The first step >> immediately enables a set of use cases that are completely blocked today. >> > > Yes to all of what Sean said- thank you, that summarizes the issue quite > well. > > I was originally of the same POV - "screw this, we already have a > mechanism for creating users, let's just use it" - but a "user" has a bunch > of specific connotations which we get entangled with and thus remain > perpetually unable to make progress on this. > > A "User" creating an "API Key" is that user authorizing an 'application' > to use the API as them. (there is a sticky use case we need to figure out > in the spec that relates to user lifecycle in shared projects) > > FWIW - I'm un-crazy about the term API Key - but I'm gonna just roll with > that until someone has a better idea. I'm uncrazy about it for two reasons: > > a) the word "key" implies things to people that may or may not be true > here. If we do stick with it - we need some REALLY crisp language about > what it is and what it isn't. > > b) Rackspace Public Cloud (and back in the day HP Public Cloud) have a > thing called by this name. While what's written in the spec is quite > similar in usage to that construct, I'm wary of re-using the name without > the semantics actually being fully the same for risk of user confusion. > "This uses api-key... which one?" Sean's email uses "APPKey" instead of > "APIKey" - which may be a better term. Maybe just > "ApplicationAuthorization"? > ++ The only strong opinion I have (yet) is that the name accurately represents what it does. Calling something one thing and having it behave differently, with respect to other known models, is the case I want to avoid. > > Anyway - I will say that this is an area where the discussion at the Forum > was very helpful in expanding my understanding and changing my opinion - to > the point where I'm now happy helping drive the spec. Score one for the > Forum! > > > __________________________________________________________________________ > 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 >
__________________________________________________________________________ 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