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

Colleen Murphy colleen at gazlene.net
Tue May 16 04:13:36 UTC 2017

On Tue, May 16, 2017 at 2:07 AM, Adrian Turjak <adriant at catalyst.net.nz>
> 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>
> On 16/05/17 14:00, Adrian Turjak wrote:

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170516/48f28c5e/attachment.html>

More information about the OpenStack-dev mailing list