Keystone auth ACL elements could be roles too

Bug #1709108 reported by Jeremy Freudberg
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Invalid
Wishlist
Unassigned

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
Revision history for this message
Alistair Coles (alistair-coles) wrote :

I think this is already supported but not documented, see bug https://bugs.launchpad.net/swift/+bug/1705300

Revision history for this message
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.

Thanks!

Revision history for this message
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 keystoneauth.py authorise method.

Revision history for this message
Jeremy Freudberg (jfreud) wrote :

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

```
e.g.
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.

Revision history for this message
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.

[1] https://bugs.launchpad.net/swift/+bug/1705300

Revision history for this message
Alistair Coles (alistair-coles) wrote :

Closing this bug. Lack of docs for this feature is being tracked here https://bugs.launchpad.net/swift/+bug/1705300

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.