Open Stack

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20161216/2ac864ae/attachment.html>