[openstack-dev] [Keystone] policy has no effect because of hard coded assert_admin?

Qiu Yu unicell at gmail.com
Fri Dec 13 05:03:39 UTC 2013


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?

#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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131213/fc9098c2/attachment.html>


More information about the OpenStack-dev mailing list