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

Monty Taylor mordred at inaugust.com
Thu May 18 22:07:20 UTC 2017

On 05/18/2017 04:32 PM, Zane Bitter wrote:
> On 18/05/17 07:53, Sean Dague wrote:
>>> My worry about policy also is that I'm not sure how safe it is for a
>>> project owned API key to inherit permissions from the user who created
>>> it. I can't think of a better way to it though but I'm still slightly
>>> uncomfortable with it since a user with more roles could make a key
>>> with  a subset of those which then someone else in the project can reset
>>> the password for and then have access to a API key that 'may' be more
>>> powerful than their own user. In clouds like ours where we allow
>>> customers to create/manage users within the scope of their own projects,
>>> there are often users who have different access all in the same project
>>> and this could be an odd issue.
>> This is a super interesting point I hadn't considered, thanks for
>> bringing it up. We could probably address it by just blocking certain
>> operations entirely for APIKeys. I don't think we loose much in
>> preventing APIKeys from self reproducing. Blocking user/pw reset seems
>> like another good safety measure (it also just wouldn't work in
>> something like LDAP, because there is no write authority). That would be
>> a very good set of things to consider on Monty's spec of any APIs that
>> we're going to explicitly prohibit for APIKeys in iteration 1.
> I can't actually think of a use case for even allowing 'password' (i.e.
> key) changes/resets. If a user wants to replace one, we should make them
> create a new API key, roll it out to their application, and then delete
> the old one. (Bonus: Heat automates this workflow for you ;)

Totally agree.

I believe I have included all of these things in the latest rev of the 
spec - but I also possibly have not.

> In the future when we have separate reader/writer roles in the default
> policy then you'll definitely require the writer role to delete an API
> key from the project (as you would for any other resource), so there'd
> be no issue AFAICT.
> cheers,
> Zane.
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list