<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 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>
</body>
</html>