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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
