<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/15/16 12:50 PM, Andrew Bogott
wrote:<br>
</div>
<blockquote
cite="mid:be71cad9-6703-6b0e-e394-172f34de4365@gmail.com"
type="cite">I'm trying to set up an unprivileged keystone account
that can query (but not modify) various openstack services.
<br>
</blockquote>
Many thanks to
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<span class="st">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks, Steve!<br>
<br>
-Andrew<br>
<br>
</span><br>
<blockquote
cite="mid:be71cad9-6703-6b0e-e394-172f34de4365@gmail.com"
type="cite">
<br>
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:
<br>
<br>
"compute:get": "",
<br>
"compute:get_all": "",
<br>
<br>
etc.
<br>
<br>
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.
<br>
<br>
The current stumbling block is that my client script needs to
enumerate projects. That looks like this:
<br>
<br>
$ openstack project list
<br>
POST <a class="moz-txt-link-freetext" href="http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens">http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens</a>
<br>
POST <a class="moz-txt-link-freetext" href="http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens">http://labcontrol1001.wikimedia.org:5000/v3/auth/tokens</a>
<br>
GET <a class="moz-txt-link-freetext" href="http://labcontrol1001.wikimedia.org:35357/v3">http://labcontrol1001.wikimedia.org:35357/v3</a>
<br>
<br>
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.
<br>
<br>
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
<br>
<br>
"identity:list_projects": "",
<br>
"identity:list_user_projects": "",
<br>
"identity:create_project": "rule:admin_required",
<br>
"identity:update_project": "rule:admin_required",
<br>
"identity:delete_project": "rule:admin_required",
<br>
<br>
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.
<br>
<br>
Am I good? Can I open up port 35357 without accidentally allowing
my read-only credentials to suddenly have 'admin' rights on
keystone?
<br>
<br>
Keystone API v3, liberty packages.
<br>
<br>
Thanks!
<br>
<br>
-Andrew
<br>
<br>
</blockquote>
<p><br>
</p>
</body>
</html>