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.math...@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.li...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev