Hi Christian, There were changes proposed recently that documented this behavior [1] [2], but they haven't been merged yet.
You're using v2.0, correct? The v2.0 API enforces policy/context at the controller layer [3], which calls assert_admin. By the looks of it, assert_admin is hardcoded to check for the 'admin_required' rule [4]. This is probably why you're seeing it work when you add the '_member_' role to the 'admin_required' rule, but not when you add '_member_' to the policy of the call. Version 3 does this a little bit differently, which uses a different mechanism than 'assert_admin' for enforcing policy [5]. It doesn't look like the filterprotected method uses the hard coded check that lives in assert_admin [6]. The behavior you're looking for might be different between v2.0 and v3. Given that it's hard coded to look for the 'admin_required' rule in v2.0, and not in v3. [1] https://review.openstack.org/#/c/123862/3 [2] https://review.openstack.org/#/c/124638/ [3] https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L36-L39 [4] https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/wsgi.py#L301 [5] https://github.com/openstack/keystone/blob/b3e969c065f991b8de180330f8f69d94012c6915/keystone/catalog/controllers.py#L226 [6] https://github.com/openstack/keystone/blob/a2667edde6e91bda0ff2c9ba6abe1015f9a7e66a/keystone/common/controller.py#L169 On Tue, Jan 27, 2015 at 11:08 AM, Fischer, Matt <matthew.fisc...@twcable.com > wrote: > On 1/26/15, 8:46 AM, "Christian Berendt" <bere...@b1-systems.de> wrote: > > >On 01/26/2015 04:02 PM, Fischer, Matt wrote: > >> Is there any reason that the user can¹t just run keystone catalog which > >> does not require admin permissions? > > > >Matt, this is just an example. We tried it with different list methods > >and it is also not working. > > > >We read your blog post about the topic > >(http://www.mattfischer.com/blog/?p=524) and it is working for us for > >services like Neutron or Nova. But not for Keystone. > > > >Christian. > > > Christian, > > I discussed this with the keystone folks this morning and it looks like > there are some internal checks for admin that are causing this. One of the > keystone team will be following-up with more details. > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
