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.li...@pobox.com <mailto: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://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
