Open Stack

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

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.