Open Stack

On 07/23/2015 10:08 AM, Matt Riedemann wrote:
>
>
> On 7/22/2015 10:18 PM, Adam Young wrote:
>> On 07/15/2015 06:38 PM, melanie witt wrote:
>>> Hi Everyone,
>>>
>>> Recently I have started reviewing the patch series about nested 
>>> quotas in nova [1] and I'm having trouble understanding where we 
>>> currently are with identity v3 support in nova. From what I read in 
>>> a semi recent proposal [2] I think things mostly "just work" if you 
>>> configure to run with v3, but there are some gaps.
>>>
>>> Nested quotas use the concept of parent/child projects in keystone 
>>> v3 to allow parent projects to delegate quota management to 
>>> subprojects. This means we'd start getting requests with a token 
>>> scoped to the parent project to modify quota of a child project.
>>
>> Don't think of it as a nested project, in this case...The project that
>> is having its quota set is a resource inside the project that the user
>> authenticated in as.
>>
>>
>> If Parent -> child...you should not be able to scope to anything but the
>> parent project in order to be able to set the quota for child.
>>
>> But, you should not be able to do anything inside of child with a token
>> scoped to parent.
>>
>> The one place this gets tricky is that every project should be able to
>> query its own quota.  But that is true now, is it not?
>
> You can, the default policy for show is admin_or_owner:
>
> http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json?id=12.0.0.0b1#n333 
>

So, this is a manifaestation of "Admin" ness not properly scoped
https://bugs.launchpad.net/keystone/+bug/968696

Note that it does not say "admin on the project" but rather "admin 
anywhere" which is endmic throughout opentstack, and something we are 
working to fix.

Policy rules that do not explicitly match scope for every token need to 
be rewritten to scope them properly.




>
>>
>>
>>>
>>> With keystone v3 we could get requests with tokens scoped to parent 
>>> projects that act upon child project resources for all APIs in general.
>>>
>>> The first patch in the series [3] removes the top-level validation 
>>> check for context.project_id != project_id in URL, since with v3 
>>> it's a supported thing for a parent project to act on child project 
>>> resources. (I don't think it's completely correct in that I think it 
>>> would allow unrelated projects to act on one another)
>>>
>>> Doing this fails the keypairs and security groups tempest tests [4] 
>>> that verify that one project cannot create keypairs or security 
>>> group rules in a different project.
>>>
>>> Question: How can we handle project_id mismatch in a way that 
>>> supports both keystone v2 and v3? Do we augment the check to fall 
>>> back on checking if "is parent of" using keystone API if there's a 
>>> project_id mismatch?
>>>
>>> Question: Do we intend to, for example, allow creation of keypairs 
>>> by a parent on behalf of child being that the private key is 
>>> returned to the caller?
>>>
>>> Basically, I feel stuck on these reviews because it appears to me 
>>> that nova doesn't fully support identity v3 yet. From what I 
>>> checked, there aren't yet Tempest jobs running against identity v3 
>>> either.
>>>
>>> Can anyone shed some light on this as I'm trying to see a way 
>>> forward with the nested quotas reviews?
>>>
>>> Thanks,
>>> -melanie (irc: melwitt)
>>>
>>>
>>> [1]https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nested-quota-driver-api,n,z 
>>>
>>> [2]https://review.openstack.org/#/c/103617/
>>> [3]https://review.openstack.org/182140/
>>> [4]http://logs.openstack.org/40/182140/12/check/check-tempest-dsvm-full/8e51c94/logs/testr_results.html.gz 
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________ 
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
>>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>