openstack team mailing list archive

[Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>]

Agreed. My suggestion (in a direct email to Jan) was:

1. A tenant (Tenant-X) has resources in Nova (VM1)
	GET nova/Tenant-X/servers/VM1        returns {name: VM1, interface:
instance-0001-eth0 }

2. A user (john) creates a network in Quantum (or in Nova? Or in Quantum
through Nova?)
	POST nova/Tenant-X/networks           returns {name: Network-A}
		Or
	POST quantum/Tenant-X/networks          returns {name: Network-A}


	Here, Quantum should store the network under the tenant (although you may
choose to track that in some other way).

3. Per your use case below:
	2.1 OK
	2.2 This would need a call to Nova. Only Nova knows whether
instance-0001-eth0 belongs to Tenant-X
		GET nova/tenants/Tenant-X/servers/VM1/interfaces/instance-0001-eth0
returns 200
	2.3 Who creates the role "plug_virtual_interface"? It sounds like this
should be a role created by Quantum (therefore
"quantum:plug_virtual_interface") and the user should have that role on
that tenant
		GET or HEAD 
keystone/tenants/Tenant-X/users/john/roles/quantum:plug_virtual_interface
  returns 200

I would not advocate creating a role for each resource. Such fine-grained
authz should probably live in the service (and not in Keystone ­ at least
not today)

Z




On 8/18/11 5:50 PM, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx> wrote:

>
>On Aug 18, 2011, at 3:45 PM, Somik Behera wrote:
>
>> Hi Vish,
>> 
>> That would be one very reasonable way to do it, but in that case we are
>>fragmenting AuthZ in multiple services instead of Keystone taking care
>>of AuthZ across all services.
>
>We can't necessarily depend on keystone to keep track of all objects
>owned by each service.  Especially for things like swift where millions
>of objects are involved.  I therefore think the right solution is to have
>the services responsible for their own objects, and allow them to
>delegate to keystone in the cases where it makes sense.
>
>> 
>> Depending on Keystone's roadmap and plans, we could take a 2 phased
>>approach, where Nova doing AuthZ is a temporary solution till Keystone
>>can do it or  if Keystone  is not going to have this capability, then we
>>go down the path you are suggesting - Keystone does AuthN and we rely on
>>Nova to authorize a tenant's access rights to a particular vif.
>> 
>> Thanks,
>> Somik

This email may include confidential information. If you received it in error, please delete it.