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 ab...@rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
