Open Stack

On Thu, Dec 12, 2013 at 11:03 PM, Qiu Yu <unicell at gmail.com> wrote:

> On Fri, Dec 13, 2013 at 2:40 AM, Morgan Fainberg <m at metacloud.com> wrote:
>
>> As Dolph stated, V3 is where the policy file protects.  This is one of
>> the many reasons why I would encourage movement to using V3 Keystone over
>> V2.
>>
>> The V2 API is officially deprecated in the Icehouse cycle, I think that
>> moving the decorator potentially could cause more issues than not as stated
>> for compatibility.  I would be very concerned about breaking compatibility
>> with deployments and maintaining the security behavior with the
>> encouragement to move from V2 to V3.  I am also not convinced passing the
>> context down to the manager level is the right approach.  Making a move on
>> where the protection occurs likely warrants a deeper discussion (perhaps in
>> Atlanta?).
>>
>>
> Thanks for the background info. However, after a quick go-through keystone
> V3 API and existing BPs. Two questions still confuse me regarding policy
> enforcement.
>
> #1 Seems V3 policy api [1] has nothing to do with the policy rules. It
> seems to be dealing with access / secret keys only. So it might be used for
> access key authentication and related control in my understanding.
>
> Is there any use case / example regarding V3 policy api? Does it even
> related to policy rules in json file?
>

The v3 policy API is intended to replace policy.json by centralizing the
persistence and management of policy rule sets.


>
> #2 Found this slides[2] online by Adam Young. And in page 27, he mentioned
> "isAdmin" currently in nova belongs to keystone actually.
>
> Would be really appreciated for some pointers. ML discussion or bp (I
> don't find any so far), etc.
>
> [1] http://api.openstack.org/api-ref-identity.html#Policy_Calls
> [2] http://www.slideshare.net/kamesh001/openstack-keystone
>
> Thanks,
> --
> Qiu Yu
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131213/90409aed/attachment.html>