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

Adrian Turjak adriant at catalyst.net.nz
Tue May 16 04:34:18 UTC 2017

On 16/05/17 16:13, Colleen Murphy wrote:
> On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak
> <adriant at catalyst.net.nz <mailto:adriant at catalyst.net.nz>> wrote:
> <snip>
>     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>"
> On Tue, May 16, 2017 at 4:10 AM, Adrian
> Turjak <adriant at catalyst.net.nz <mailto:adriant at catalyst.net.nz>> wrote:
>     On 16/05/17 14:00, Adrian Turjak wrote:
> <snip> 
>>     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?
>>     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.
>>     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.
>     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.
> It's not just expiry. I think your proposal is missing one of the
> major use cases: empowerment of non-admin users. A non-admin can't
> create new users themselves, they have to (as you've pointed out) ask
> an admin to do it for them. As an application developer, I want to be
> able to delegate a subset of my own roles to a programmatic entity
> without being dependent on some other human. One of the (numerous)
> specs proposed seeks to address that use
> case: https://review.openstack.org/#/c/396634
> Colleen

That still doesn't seem like justification enough to make an entirely
new auth type and 'user-lite' model. The problem is that you have to be
admin to create users, that shouldn't have to be the case. You should be
able to create users, but ONLY give them roles for your projects or your
project tree. Keystone doesn't do that, and there is no way with policy
to do that currently. Hell, we wrote a service just to do that on behalf
our customers since keystone didn't give us that that level of control,
and because we really didn't want them needing an admin to do it for them.

So the features we are after are:
- the ability as a non-admin to create user or user-like access objects.
- the ability to maybe expire those

This is still sounding like a feature to get around flaws in the current
system rather than fix those flaws. Are we saying it is easier and
better to introduce more models and complexity than fix the existing
system to make it useful? We only did it in an external service because
we had additional requirements that didn't fit fit into core keystone,
but then ended up with a nice place to do some wrapper logic around the
limited keystone user management.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/b288d9f3/attachment.html>

More information about the OpenStack-dev mailing list