[openstack-dev] [all][keystone][product] api keys/application specific passwords

Adrian Turjak adriant at catalyst.net.nz
Tue May 16 00:07:56 UTC 2017


On 16/05/17 01:09, Lance Bragstad wrote:
>
>
> On Sun, May 14, 2017 at 11:59 AM, Monty Taylor <mordred at inaugust.com
> <mailto:mordred at inaugust.com>> wrote:
>
>     On 05/11/2017 02:32 PM, Lance Bragstad wrote:
>
>         Hey all,
>
>         One of the Baremetal/VM sessions at the summit focused on what
>         we need
>         to do to make OpenStack more consumable for application
>         developers [0].
>         As a group we recognized the need for application specific
>         passwords or
>         API keys and nearly everyone (above 85% is my best guess) in
>         the session
>         thought it was an important thing to pursue. The API
>         key/application-specific password specification is up for
>         review [1].
>
>         The problem is that with all the recent churn in the keystone
>         project,
>         we don't really have the capacity to commit to this for the
>         cycle. As a
>         project, we're still working through what we've committed to
>         for Pike
>         before the OSIC fallout. It was suggested that we reach out to
>         the PWG
>         to see if this is something we can get some help on from a
>         keystone
>         development perspective. Let's use this thread to see if there
>         is anyway
>         we can better enable the community through API
>         keys/application-specific
>         passwords by seeing if anyone can contribute resources to this
>         effort.
>
>
>     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.
>
>
> 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].
>
>
> [0] https://review.openstack.org/#/c/440593/
>  
>

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)?


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:
username: "service_user_for_web_app_1@<project_id>"
password: "<some_generated_password>"

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/68b1a868/attachment-0001.html>


More information about the OpenStack-dev mailing list