Open Stack

this is great, Tom.

product team should be able to roll this into a support and get to work on Shepard it to the dev team.

--Rocky

Sent from HUAWEI AnyOffice
From:Tom Fifield
To:user-committee at lists.openstack.org
Date:2017-01-26 21:01:29
Subject:[User-committee] [Product] Admin-ness+Quota needs write-up

Hi Product Team,

Here's a nice use-case write-up that details a need regarding admin role
scoping in keystone and quotas

Regards,

Tom


-------- Forwarded Message --------
Subject:         [Openstack-operators] Delegating quota management for all
projects to a user without the admin role?
Date:    Thu, 26 Jan 2017 23:36:10 -0000
From:    Edmund Rhudy (BLOOMBERG/ 120 PARK) <erhudy at bloomberg.net>
Reply-To:        Edmund Rhudy <erhudy at bloomberg.net>
To:      openstack-operators at lists.openstack.org



I'm looking for a way to allow a user that does not have the admin role
to be able to view and set quota (both Nova/Cinder) for all projects in
an OpenStack cluster. For us, the boundary of a Keystone region is
coterminous with an OpenStack cluster - we don't currently use any sort
of federated Keystone.

Background: we are involved in a project (not the Keystone variety) for
integrating Bloomberg's internal budget processes closely with
purchasing compute resources. The idea of this system is that you will
purchase some number of standardized compute units and then you can
allocate them to projects in various OpenStack clusters as you wish. In
order to do this, the tool needs to be able to see what Keystone
projects you have access to, see how much quota that project has, and
modify the quota settings for it appropriately.

For obvious reasons, I'd like to keep the API access for this tool to a
minimum. I know that if all else fails, the goal can be accomplished by
giving it admin access, so I'm keeping that in my back pocket, but I'd
like to exhaust all reasonable options first.

Allowing the tool to see project memberships and get project information
is easy. The quota part, however, is not. I'm not sure how to accomplish
that delegation, or how to give the tool admin-equivalent access for a
very small subset of the APIs. I'm unfamiliar with Keystone trusts and
am not sure it would be appropriate here anyway, because it would seem
like I'd need to delegate admin control to the role user in order to
allow quota get/set. The only other thing I can think of, and it seems
really off the wall to me, is to:

* create a local domain in Keystone
* create one user in this local domain per every Keystone project and
add it to that project
* give this user a special role that allows it to set quotas for its project
* set up a massive many-to-one web of trusts where all of these users
are delegated back to the tool's account

This solution seems very convoluted, and the number of trusts the tool
will need to know about is going to grow linearly with the number of
projects in Keystone.

The clusters in question are all running Liberty, with Keystone v3
available. Keystone is in a single-domain configuration, where the
default domain is sourcing users from LDAP and all other information is
stored in SQL.

Anyone have any thoughts, or am I SOL and just have to give this thing
admin access and make sure the creds stay under lock and key?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170127/ac286073/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Attached Message Part
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170127/ac286073/attachment-0001.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170127/ac286073/attachment-0001.txt>