openstack team mailing list archive

[Jorge Williams <jorge.williams@xxxxxxxxxxxxx>]

We called them "Resource Groups" because we wanted to make a distinction between them and "User Groups" .  We feel, we need to support both.   Based on your IRC conversation,  I think  there seems to be a confusion between both kinds of groups so let me take a step back and explain our thinking. 

We're really looking to solve two separate use cases:

Use Case #1 (User Groups):

You are managing a large set of resources (instances, databases, load balancers, files, etc).  You have different groups of people that work for you and you want to assign them different privileges.  You can create a group called "Admins", assign full privileges to all of your resources and you can place all of your sys admins in that group.  You can create a different group call "DBAdmins"  and give enough privileges to administer your databases and so on.  You can add and remove users from  groups. Individuals can  exist in multiple groups and you can change the privileges associated with each group at anytime.

Use Case #2 (Delegation):

Company M provides monitoring services for instances.   You want Company M to have access to a subset of your resources.  For example you want them to monitor your production servers but you don't want them to be able to access  your staging or development environments.  Additionally, they should only be able to perform read operations on the instance and should not be able to issue actions such as "reboot" or "rebuild", etc. You can revoke M's access or otherwise change the privileges associated with M at anytime.  You should not have to give M your credentials.

In use case #1, permissions are assigned to a group and individual users are placed in one or more groups:

G[1] -> {P[1], P[2], P[3], P[4]} 
U[1] -> {G[1], G[2]}

In use case #2, permissions are instead assigned to a "refresh" token (see OAuth 2 spec).  This token (T[1]) is offered to M and is used (after it's traded in for an access token) to get access to resources.

T[1] -> {P[4], P[5], P[6], P[7]}

Why not simply create a group for Company M and assign permissions to that group?  We could do this, but it turns out that's not very useful for M.  From Company M's perspective, when working on your account, getting a list of servers should return only the servers that you've given them access to. They should not see instances that belong to other customers etc.  This simplifies their code a lot. M doesn't need to necessarily  sort out whom resources belong to -- instead they need only keep track of who each token belongs to.  Also tokens allow us to  keep track of "on behave of" which works out great for billing.

Note that we're not planning on assigning privileges to users directly.  Instead when a user is created it's assigned a refresh token like M is.  Privileges are assigned to that token.  User's may themselves enter into delegation which means that there may be several tokens assigned to a single user.  When the user launches an operation their set of permissions is the sum of all of the permissions associated with their refresh token PLUS the set of permissions  associated with each group the user belongs to. 

Up until now, I haven't discussed resource groups.  Resource groups are used to help define a permission (P[x]).  We say that a permission is a capability (C[x]), such as "reboot", "create server",  plus a set of Resource Group IDs (RGID[x]) -- these IDs must be globally unique.

P[1] = { C[1], {RGID[1], RGID[2],  RGID[3]}}

As Sandy has described, each service (or Zone in nova) is responsible for maintaining the group of resources associated with the ID.  These groups are created and managed by users as part of the delegation process.  The same resource group ID can be used to combine resources from multiple zones or services.  For example, RGID 0x19a8c73  may be associated with instance 5 and 6 in Zone 1 and instance 10 in Zone 2 and with Load balancer 8 in the load balancing service.  The logical resource group contains all of those resources, but all Zone 1 knows is that 5, 6 are associated with 0x19a8c73.  And that's all it needs to know, when a requests comes in, Zone 1 validates the token and asks for all permissions that are associated with it (that is the sum of token and group permissions) -- the service may ask to narrow the set of permissions it gets to only those that make sense to compute.  Then Zone 1 checks the capability with the operation and makes sure that the instance is a member of one of the RGIDs.

That's the thinking so far.  It's not a perfect solution, and it's not set in stone,  but it does provide a path to useful delegation with OAuth 2.0.

Thoughts?

-jOrGe W.

On Apr 6, 2011, at 6:31 AM, Sandy Walsh wrote:

> Myself and Eric were chatting a little more about this on IRC yesterday http://paste.openstack.org/show/1108/
> 
> Eric made an interesting observation that we don't need to call them Resource Groups, since they're just collections of UUID's (or URI's or URN's or whatever). They could refer to Users, other Resource Groups, Instances, Projects, whatever. 
> 
> So, starting off, new Resources are created with the User ID as the owner. Later, when MyCo.authz passes the permission tuples to SP, they could include the UUID of the user. If the instance needed to be controlled by a group of people, the owner of the resource could be changed to be a User Group.
> 
> This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually.
> 
> Eric suggested calling them Entity Groups vs Resource Groups. (aside: I find Entity is a pretty overloaded term ... perhaps Security Groups?)
> 
> Seems reasonable to me? If people agree, I'll update the wiki to reflect the changes.
> 
> -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.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp