<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 16, 2017 at 8:54 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 05/16/2017 05:39 AM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/15/2017 10:00 PM, Adrian Turjak wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 16/05/17 13:29, Lance Bragstad wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Mon, May 15, 2017 at 7:07 PM, Adrian Turjak<br>
<<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a> <mailto:<a href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.n<wbr>z</a>>> wrote:<br>
</blockquote></blockquote>
<snip><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Based on the specs that are currently up in Keystone-specs, I<br>
would highly recommend not doing this per user.<br>
<br>
The scenario I imagine is you have a sysadmin at a company who<br>
created a ton of these for various jobs and then leaves. The<br>
company then needs to keep his user account around, or create tons<br>
of new API keys, and then disable his user once all the scripts he<br>
had keys for are replaced. Or more often then not, disable his<br>
user and then cry as everything breaks and no one really knows why<br>
or no one fully documented it all, or didn't read the docs.<br>
Keeping them per project and unrelated to the user makes more<br>
sense, as then someone else on your team can regenerate the<br>
secrets for the specific Keys as they want. Sure we can advise<br>
them to use generic user accounts within which to create these API<br>
keys but that implies password sharing which is bad.<br>
<br>
<br>
That said, I'm curious why we would make these as a thing separate<br>
to users. In reality, if you can create users, you can create API<br>
specific users. Would this be a different authentication<br>
mechanism? Why? Why not just continue the work on better access<br>
control and let people create users for this. Because lets be<br>
honest, isn't a user already an API key? The issue (and the Ron's<br>
spec mentions this) is a user having too much access, how would<br>
this fix that when the issue is that we don't have fine grained<br>
policy in the first place? How does a new auth mechanism fix that?<br>
Both specs mention roles so I assume it really doesn't. If we had<br>
fine grained policy we could just create users specific to a<br>
service with only the roles it needs, and the same problem is<br>
solved without any special API, new auth, or different 'user-lite'<br>
object model. It feels like this is trying to solve an issue that<br>
is better solved by fixing the existing problems.<br>
<br>
I like the idea behind these specs, but... I'm curious what<br>
exactly they are trying to solve. Not to mention if you wanted to<br>
automate anything larger such as creating sub-projects and setting<br>
up a basic network for each new developer to get access to your<br>
team, this wouldn't work unless you could have your API key<br>
inherit to subprojects or something more complex, at which point<br>
they may as well be users. Users already work for all of this, why<br>
reinvent the wheel when really the issue isn't the wheel itself,<br>
but the steering mechanism (access control/policy in this case)?<br>
<br>
<br>
All valid points, but IMO the discussions around API keys didn't set<br>
out to fix deep-rooted issues with policy. We have several specs in<br>
flights across projects to help mitigate the real issues with policy<br>
[0] [1] [2] [3] [4].<br>
<br>
I see an API key implementation as something that provides a cleaner<br>
fit and finish once we've addressed the policy bits. It's also a<br>
familiar concept for application developers, which was the use case<br>
the session was targeting.<br>
<br>
I probably should have laid out the related policy work before jumping<br>
into API keys. We've already committed a bunch of keystone resource to<br>
policy improvements this cycle, but I'm hoping we can work API keys<br>
and policy improvements in parallel.<br>
<br>
[0] <a href="https://review.openstack.org/#/c/460344/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/460344/</a><br>
[1] <a href="https://review.openstack.org/#/c/462733/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/462733/</a><br>
[2] <a href="https://review.openstack.org/#/c/464763/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/464763/</a><br>
[3] <a href="https://review.openstack.org/#/c/433037/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/433037/</a><br>
[4] <a href="https://review.openstack.org/#/c/427872/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/427872/</a><br>
<br>
</blockquote>
I'm well aware of the policy work, and it is fantastic to see it<br>
progressing! I can't wait to actually be able to play with that stuff!<br>
We've been painstakingly tweaking the json policy files which is a giant<br>
mess.<br>
<br>
I'm just concerned that this feels like a feature we don't really need<br>
when really it's just a slight variant of a user with a new auth model<br>
(that is really just another flavour of username/password). The sole<br>
reason most of the other cloud services have API keys is because a user<br>
can't talk to the API directly. OpenStack does not have that problem,<br>
users are API keys. So I think what we really need to consider is what<br>
exact benefit does API keys actually give us that won't be solved with<br>
users and better policy?<br>
</blockquote>
<br>
The benefits of API key are if it's the same across all deployments, so<br>
your applications can depend on it working. That means the application<br>
has to be able to:<br>
<br>
1. provision an API Key with normal user credentials<br>
2. set/reduce permissions with that with those same user credentials<br>
3. operate with those credentials at the project level (so that when you<br>
leave, someone else in your dept can take over)<br>
4. have all it's resources built in the same project that you are in, so<br>
API Key created resources could interact with manually created resources.<br>
5. revoke at any time (and possibly bake in an expiration to begin with)<br>
<br>
#1 means these can't just be users. By the user survey 30% are using<br>
LDAP/AD, which means the authority to create a user isn't even cloud<br>
admin level, it's company AD level. It may literally be impossible to do.<br>
<br>
#2 means permissions can't be done with roles. Normal users can't create<br>
roles, and roles don't properly express permissions inherent in them<br>
either. Even if users started to be able to create roles, that would<br>
mean an incredible role explosion.<br>
<br>
#2 also means this interface can't use policy. Policy an internal<br>
structure for operators setting allow points, and is a DSL that we<br>
*really* don't want to make everyone learn every bit of.<br>
<br>
#4 means this can't be done with special projects where users could<br>
create other users using the existing SQL split backend setup in<br>
keystone (even if they had AD). This is complicated to setup in the<br>
first place, but if API Key created servers aren't able to get to the<br>
network that was manually setup in a different tenant, the usefulness is<br>
limited.<br>
<br>
<br>
This is why the proposal out of the room going forward was some concrete<br>
steps:<br>
<br>
1) Make a new top level construct of an APPKey that exists within a<br>
project, that all users can create in projects they are members of.<br>
<br>
This immediately solves #1. And even inheriting Member role becomes<br>
useful because of the revoke facility. There are now a set of<br>
credentials that are ephemeral enough to back into images / scripts,<br>
that aren't also getting into your health records or direct deposit at<br>
your company.<br>
<br>
2) Provide a mechanism to reduce what these APPKeys can do. Policy &<br>
Roles is actually the wrong approach, those are operator constructs. API<br>
consuming things understand operations in terms of ("Region1",<br>
"compute", "/servers", "GET"). Something along those lines would be<br>
provided as the way to describe permissions from a user.<br>
<br>
The complaint is this is a second way of describing permissions. It is.<br>
But the alternative to teach our entire user base about policy name<br>
points is ... far less appealing. We should be tailoring this to the<br>
audience we want to consume it.<br>
<br>
<br>
Yes, these are 2 distinct steps, but I think it's disengenous to say the<br>
first step is pointless until the second one is done. The first step<br>
immediately enables a set of use cases that are completely blocked today.<br>
</blockquote>
<br></div></div>
Yes to all of what Sean said- thank you, that summarizes the issue quite well.<br>
<br>
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.<br>
<br>
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)<br>
<br>
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:<br>
<br>
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.<br>
<br>
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"?<br></blockquote><div><br></div><div>++</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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!<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>