openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

From: Vishvananda Ishaya [vishvananda@xxxxxxxxx]
> Eric:
> I agree that your suggestion is simpler, but I think we are too limited if we remove multi-membership and per-
> object overrides.  Imagine that alice is an organization that has 10 users and a lot of instances.  If i create a group
> called alice_shares, then I have to remember to add all of other 10 users of alice to that group, and the instances
> are no longer logically grouped because they will show up at a different url or require a different set of 
> credentials to access.  This sucks from a usability perspective.  I should also mention that if we are going
> to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet
>  and jump into multiple ownership.

Agree, as per my previous email. I think the effort to support multiple user accounts is no different than managing multiple resource groups. 

> The original proposal was to keep a single owner, but allow resources to be overridden individually.  [...]
> I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of
> objects below the ownership level.

The override concept give me pause. It seems like unnecessary work when the problem can be handled easier by assigning ownership to a Resource to a group vs a single user. 

> The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources 
> and give access to all of them.  In this scenario, the instances would still have alice as the owner, but some of them
> would be tagged "alice_shares".  These can actually be subject groups, but there has to be a mapping of resources
> to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, 
> perhaps even using instance metadata.  The drawback of this method is that it essentially boils down to multiple-
> ownership and requires auth api additiions to allow group creation and modification.

I like tags, they scale well. But they work best as way of representing static metadata (think bookmarks in delicio.us) ... if the tags are changing frequently then groups are easier to update (vs. running around to all instances that need tags added/removed)

> Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to
>  occur that maintains some usability.

>From my discussion with Jorge, much of this functionality is present in the existing Rackspace authz system and on the roadmap for inclusion. It is modeled on existing SAML and RBAC approaches. It should work easily with LDAP containers as well. 

-S

Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.