<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 16/05/17 14:00, Adrian Turjak wrote:<br>
</div>
<blockquote
cite="mid:6ff52f3d-c779-b948-e8e6-05578fc024e6@catalyst.net.nz"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 16/05/17 13:29, Lance Bragstad
wrote:<br>
</div>
<blockquote
cite="mid:CAE6oFcGiVjXHUfJaOzbi1BRc3FUF9FrjOVRsW7UaCMy1TfGPHQ@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, May 15, 2017 at 7:07 PM,
Adrian Turjak <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:adriant@catalyst.net.nz" target="_blank">adriant@catalyst.net.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-"> <br>
<div
class="gmail-m_-4292636395557196316moz-cite-prefix">On
16/05/17 01:09, Lance Bragstad wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, May 14, 2017
at 11:59 AM, Monty Taylor <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mordred@inaugust.com"
target="_blank">mordred@inaugust.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span
class="gmail-m_-4292636395557196316gmail-">On
05/11/2017 02:32 PM, Lance Bragstad
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Hey all,<br>
<br>
One of the Baremetal/VM sessions at
the summit focused on what we need<br>
to do to make OpenStack more
consumable for application developers
[0].<br>
As a group we recognized the need for
application specific passwords or<br>
API keys and nearly everyone (above
85% is my best guess) in the session<br>
thought it was an important thing to
pursue. The API<br>
key/application-specific password
specification is up for review [1].<br>
<br>
The problem is that with all the
recent churn in the keystone project,<br>
we don't really have the capacity to
commit to this for the cycle. As a<br>
project, we're still working through
what we've committed to for Pike<br>
before the OSIC fallout. It was
suggested that we reach out to the PWG<br>
to see if this is something we can get
some help on from a keystone<br>
development perspective. Let's use
this thread to see if there is anyway<br>
we can better enable the community
through API keys/application-specific<br>
passwords by seeing if anyone can
contribute resources to this effort.<br>
</blockquote>
<br>
</span> 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.<br>
</blockquote>
<div><br>
</div>
<div>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].</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/440593/"
target="_blank">https://review.openstack.<wbr>org/#/c/440593/</a></div>
<div> </div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</span> Based on the specs that are currently up in
Keystone-specs, I would highly recommend not doing
this per user.<br>
<br>
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.<br>
<br>
<br>
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.<br>
<br>
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)?<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>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].</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>[0] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/460344/">https://review.openstack.org/#/c/460344/</a><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/462733/">https://review.openstack.org/#/c/462733/</a><br>
</div>
<div>[2] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/464763/">https://review.openstack.org/#/c/464763/</a><br>
</div>
<div>[3] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/433037/">https://review.openstack.org/#/c/433037/</a><br>
</div>
<div>[4] <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/427872/">https://review.openstack.org/#/c/427872/</a><br>
</div>
<br>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
</blockquote>
<br>
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.<br>
</body>
</html>