No problem Andrew! Glad I could help. In case folks want to read the chat: http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2016-12-16.log.html#t2016-12-16T16:47:59
stevemar On Fri, Dec 16, 2016 at 2:32 PM, Andrew Bogott <[email protected]> wrote: > On 12/15/16 12:50 PM, Andrew Bogott wrote: > > I'm trying to set up an unprivileged keystone account that can query (but > not modify) various openstack services. > > Many thanks to Steve Martinelli who helped me sort this out on IRC > today. As I understand it, with the v3 keystone api there's no longer a > clear distinction between an 'admin' and 'user' api -- they're all the same > API. My problem was just that the keystone client was trying to be polite > and use the 'admin' endpoint for historical reasons. > > Semi-modern versions of the keystone and openstack client support > "--os-interface public" which just sends all queries to the public > endpoint, thus avoiding all of my issues with the admin api firewall. > > As it happens, the version of the clients that ships with Debian Jessie > does not support this arg, hence my confusion. After a day of backporting > I should be in business. > > Thanks, Steve! > > -Andrew > > > > This is generally going pretty well. I've added an account with a no-op > role ('observer') and then modified a bunch of my policy files to permit > read-only queries: > > "compute:get": "", > "compute:get_all": "", > > etc. > > I also opened up firewalls to allow my client tools to access the public > (but not admin) keystone, glance, nova and designate APIs. My public > keystone API is on port 5000, and the admin keystone API on 35357. > > The current stumbling block is that my client script needs to enumerate > projects. That looks like this: > > $ openstack project list > POST http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens > POST http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens > GET http://labcontrol1001.wikimedia.org:35357/v3 > > Apparently the keystone client recognizes that the 'project list' action > requires the keystone admin API, so it hits port 35357 (firewalled) rather > than 5000 (which is not firewalled.) So the easy fix is to poke a hole in > my firewall for port 35357. > > This reminds me that I don't really understand the distinction between the > 'admin' and the 'public' APIs. They respond to different queries, > clearly. But... is simply having access to the admin api a privilege > escalation, or is the admin api just another set of calls that are governed > by all the same policy checks? It looks to me like it's safe to expose > 35357 because keystone policy is > > "identity:list_projects": "", > "identity:list_user_projects": "", > "identity:create_project": "rule:admin_required", > "identity:update_project": "rule:admin_required", > "identity:delete_project": "rule:admin_required", > > And of course I'm not exposing credentials for an admin account. But when > I look at nova's policy it has a rule called 'admin_api' which suggests > that the policy engine is making some kind of rule distinction based on > what port a command is coming in on... and that scares me. > > Am I good? Can I open up port 35357 without accidentally allowing my > read-only credentials to suddenly have 'admin' rights on keystone? > > Keystone API v3, liberty packages. > > Thanks! > > -Andrew > > > > _______________________________________________ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > Post to : [email protected] > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
