Keystone auth ACL elements could be roles too

Bug #1709108 reported by Jeremy Freudberg on 2017-08-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)

Bug Description

Per-container ACLs when using Keystone auth can have project-id and user-id elements. But this means for an application to share a container with many users, it has to maintain a long list, which can get messy.
(basically, where do you keep track, how do you remove just one user from the list, etc)

Role-based ACLs could do a great job of making ACLs easier to maintain.

If roles can be consumed, then granting access to a container becomes much simpler. The operator can set a standard ACL referring to a custom role, and instead of constantly talking to Swift to modify an unwieldy list, he may simply assign the role to a user as he sees fit.

Changed in swift:
importance: Undecided → Wishlist
Alistair Coles (alistair-coles) wrote :

I think this is already supported but not documented, see bug

Jeremy Freudberg (jfreud) wrote :

Hi Alistair, sorry, I'm having trouble understanding the example on that bug you linked. Where does the role's presence actually get evaluated in the example?

Nevertheless, It does look promising as that `user_roles` list in the highlighted code does eventually trickle down to HTTP_X_ROLES environment, which does contain what I want.


Alistair Coles (alistair-coles) wrote :

Jeremy, I'm on vacation and don't have access to code etc but from memory the role ACL is evaluated towards the end of the swift authorise method.

Jeremy Freudberg (jfreud) wrote :

Alistair, if I wasn't clear, by "having trouble understanding the example", I meant not understanding this:

create a project test and create a container c1 in that project account
create a user 'other' in keyctone with role 'not_admin' on project test
get a token for user other *scoped on prject test*
GET AUTH_test/c1/<an object> fails using the token -> fails, not permitted
set 'X-Container-Read = other' on c1
GET AUTH_test/c1/<an object> fails using the token -> ok

I'm assuming X-Container-Read should be "not_admin", not "other"?

Please continue your vacation. I'm sure I can manage by getting help from a different team member until your return.

Alistair Coles (alistair-coles) wrote :

Jeremy, - apologies, the example I left on [1] was (as you spotted) wrong. I have fixed that and just re-checked the use of role in container ACLs. I hope you made progress in the meantime.


Alistair Coles (alistair-coles) wrote :

Closing this bug. Lack of docs for this feature is being tracked here

Changed in swift:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers