openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

On Thu, Apr 07, 2011 at 11:54:26AM +0000, Sandy Walsh wrote:
> > 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.
> 
> Yes, this is a slight variation on our previous discussions, but I like it. 
> What we're saying is that Instance (resource) names will be prefixed with container names and permissions will be applied to containers. 

Not really. We don't have containers in Nova now, and I don't think
we really need them. I just meant that owner is a required parameter
when creating an instance, so the API needs to get it from somewhere
(default to authenticated user, from path, json param, etc). The
above could be POST /v1.1/servers just like it is today, and <owner>
was given in the JSON of the request body. owner required just like
flavor, image, etc.

> and place the permissions at the top of the tree. Or,
> 
> /instances/finance/myco/ami-***
> /instances/finance/SP/ami-***
> 
> and place the permissions at the /instances/finance level ... but how would these transfer across the public/private zone boundaries? (since MyCo.authz controls the permissions and SP.authz just enforces it)

What do you mean SP.authz enforces? SP.authz should not ever be
contacted when dealing with MyCO.authz users, no?

> > > 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.
> 
> In this scenario chgrp() would equate to a move() operation ... to move from one "container" to another. 

Hmm, you lost me here. :)

> > 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".
> 
> Not sure if I like the idea of read/write permissions vs. Rights (strings), but that's a side discussion. 

I was reviewing what Swift does above, not making suggestions for Nova.

> > 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.
> 
> Can't the user just create the container first and then create the instance in the container?

As I mentioned above, I don't think we should introduce "containers",
which gets back to the issue of how to grant group-level permission
without a resource (such as ability to create new resources). Switching
from the swift style group list to (group,action) list solves this.

> > 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.
> 
> I'm not clear how we ended up with permissions in two places? I thought the AuthZ would manage the tree of containers and permissions, not the services. The service would just do the permission check. 
> 
> Are you talking about per-resource overrides on the authz permissions?

Yes. We could have authz for an entity return:

[(group A, can_create), (group B, can_reboot)]

and a permission list on an instance owned by group C with:

[(group B, can_add_floating_ip)]

Now, since the entity has group B, can they, add_floating_ip, both,
or neither? In other words, how are the permission sets combined? If
we need to make this configurable, should this be stored along with
the tuple? I'm leaning towards keeping it simple and simply use the
most specific set, and don't combine them, but I could see other cases.

There are some other questions about how to just say use group B's
default permissions that are returned from authz for a resource. How
would this be stored on the resource, group without action? We would
need some 'use_default' marker for the action.

-Eric