<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 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 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 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 href="https://review.openstack.org/#/c/460344/">https://review.openstack.org/#/c/460344/</a><br></div><div>[1] <a href="https://review.openstack.org/#/c/462733/">https://review.openstack.org/#/c/462733/</a><br></div><div>[2] <a href="https://review.openstack.org/#/c/464763/">https://review.openstack.org/#/c/464763/</a><br></div><div>[3] <a href="https://review.openstack.org/#/c/433037/">https://review.openstack.org/#/c/433037/</a><br></div><div>[4] <a href="https://review.openstack.org/#/c/427872/">https://review.openstack.org/#/c/427872/</a><br></div><div> </div><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">
<br>
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:<br>
username: "service_user_for_web_app_1@<<wbr>project_id>"<br>
password: "<some_generated_password>"<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
</div>
<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>