openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

On Wed, Apr 06, 2011 at 11:31:35AM +0000, 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.

Well, they should start off with what the request specifies. For
the 1.1 API, this takes the for of POST /v1.1/<owner>/servers/ so
<owner> would be the owner. This could be anything depending on what
the authenticated user has access to do and what the authz system
defines for types, but Nova doesn't care as it's just a string.

> 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.

Well, we may not always want to change the owner for this, we may
want to simply add to the list of entities (user/groups/whatever)
that can access it. Owner alone is not enough.

> Eric suggested calling them Entity Groups vs Resource Groups. (aside: I find Entity is a pretty overloaded term ... perhaps Security Groups?)

Security groups overlap with the network permissions names, so I'm
not sure that's a good choice either. Last time I suggested entity
folks preferred 'account', which is fine too. I think account still
implies some context, but I don't care enough to spend time on what
we call it. :)

One thing to also think about is where we actually describe
permissions. I mentioned this briefly in a previous thread, but I
think this needs more exploration.

Lets approach authz as looking at what Swift does today and expanding
on it. A authenticated user in swift gets a list of 'groups' that
user belongs to. This is just like what we've been talking about,
except swift only has group name, not (group,action) tuples. A name
in the group list can be anything, from another account, a tag,
whatever. It's just a string. For now lets use 'group' and mean
account/entity/whatever from above.

There are then permissions on containers that specify actions for
groups (think of group/action tuples on a resource). So if container
X has write permission for group A, a user with group A in their
list can insert objects there. The shortcoming with this model
is that you need a resource to exist to assign permissions to it
(for example, a container needs to be created by the account owner
first). I asked Chuck and it sounds like you can't specify "group A
can create containers for group/account B".

In Nova, and probably other services, we want the ability to specify
actions for groups when a resource doesn't exist. For example, I
want to give group A the ability to create instances for group B,
but there is no container resource yet. The obvious way to solve this
is to do what we've been discussing and have the authz system return
not just group name, but (group,action) tuples.

The question now is do we restrict the types of actions that can be
specified in the authz system vs per-resource for a service? If you
can specify can_reboot in both the authz system and per-resource,
how are ambiguities resolved?

For example, the authz system may return (group A, [can_create,
can_reboot]), but an instance record may contain the permission
tuple (group A, can_associate_ip). What can group A really do to
that instance? Is it the union, intersection, or the most specific
set of actions? If we design our authz in this way, we just need to
be aware and choose.

-Eric