From: Eric Day [e...@oddments.org] > 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. It's good because it solves the problem of "on behalf of". However, what I need to wrap my head around is how this would work in a federated fashion. MyCo has a container structure and SP has a container structure. We need to manage permissions on: /myco/instances/finance/ami-**** /myco/instances/alice/ami-**** /myco/instance/bob/ami-*** /sp/myco/instances/finance/ami-*** /sp/myco/instances/alice/ami-*** /sp/myco/instances/bob/ami-*** 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) >From an end-user perspective, does Alice or Bob need to know to manage >permissions for MyCo and for the situations when the instances live with SP? I need to stew on that some more. > > 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. > but I don't care enough to spend time on what we call it. :) +1 > 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. With Rights we could grant permission for a user to create a new container and assign Account B access to it. can_create_container, can_change_owner Or perhaps I'm missing the subtly here. > 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? > 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? -S > -Eric 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
