Open Stack

On 05/05/2016 05:54 PM, Dolph Mathews wrote:
> My understanding from the summit session was that we should have a 
> specific role defined in keystone's policy.json here:
>
> https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37
>
> Which grants access to nothing in keystone beyond that check. So, the 
> new rule could be revised to something as generic as:
>
>   "identity:get_project": "rule:admin_required or 
> project_id:%(target.project.id <http://target.project.id>)s or 
> role:identity_get_project",
>
> Where the new role name I appended at the end exactly matches the 
> policy rule name.
Would we expect the have the implied rule that Member implies 
identity_get_project?


>
> However, unlike the summit discussion, which specified only providing 
> access to HEAD /v3/projects/{project_id}, keystone's usage of policy 
> unfortunately wraps both HEAD and GET with the same policy check.
>
> On Thu, May 5, 2016 at 3:05 PM Augustina Ragwitz 
> <aragwitz.lists at pobox.com <mailto:aragwitz.lists at pobox.com>> wrote:
>
>     I'm currently working on the spec for Project ID Validation in Nova
>     using Keystone. The outcome of the Design Summit Session was that the
>     Nova service user would use the Keystone policy to establish
>     whether the
>     requester had access to the project at all to verify the id. I was
>     wondering if there were any code examples of a non-Keystone service
>     using the Keystone policy in this way?
>
>     Also if I misunderstood something, please feel free to correct me
>     or to
>     clarify!
>
>     Here is the etherpad from the session:
>     https://etherpad.openstack.org/p/newton-nova-keystone
>     And here is the current spec: https://review.openstack.org/#/c/294337
>
>
>     --
>     Augustina Ragwitz
>     Sr Systems Software Engineer, HPE Cloud
>     Hewlett Packard Enterprise
>     ---
>     irc: auggy
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -- 
> -Dolph
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160505/451b156d/attachment.html>