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
