Open Stack

+1

Would love to see more WGs proposing more use-cases, like this.

These would be great conversations starters at the summit (forum) as well
IMHO.

/dff

On Sat, Jan 28, 2017 at 7:03 AM, Rochelle Grober <rochelle.grober at huawei.com
> wrote:

> 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?
>
> _______________________________________________
> User-committee mailing list
> User-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/user-committee
>
>


-- 
Flanders | OpenStack Foundation | Community Manager (Cloud Application
Communities)
http://superuser.openstack.org/articles/meet-openstack-s-
community-wrangler-david-flanders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/user-committee/attachments/20170128/df7ed413/attachment-0001.html>