Open Stack

I don't see that we need a new role for this because it would need to be
added to all the admin users. I was thinking just admin or
target.project_id==token.project_id. Hopefully in future this would get
better because we can get nova to send the service token as well and
enforce that it came from another service as well.

On 6 May 2016 at 07:54, Dolph Mathews <dolph.mathews at gmail.com> 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)s or role:identity_get_project",
>
> Where the new role name I appended at the end exactly matches the policy
> rule name.
>
> 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>
> 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://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/20160510/3dcfbc0f/attachment.html>