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" <[email protected]> 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.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
