<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>this is great, Tom.<br>
<br>
product team should be able to roll this into a support and get to work on Shepard it to the dev team.<br>
<br>
--Rocky<br>
<br>
Sent from HUAWEI AnyOffice<br>
</div>
<div name="x_AnyOffice-Background-Image" style="border-top:1px solid #B5C4DF; font-size:14px; line-height:20px; padding:8px">
<div style="word-break:break-all"><b>From:</b>Tom Fifield</div>
<div style="word-break:break-all"><b>To:</b>user-committee@lists.openstack.org</div>
<div style="word-break:break-all"><b>Date:</b>2017-01-26 21:01:29</div>
<div style="word-break:break-all"><b>Subject:</b>[User-committee] [Product] Admin-ness+Quota needs write-up</div>
<div><br>
</div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi Product Team,<br>
<br>
Here's a nice use-case write-up that details a need regarding admin role <br>
scoping in keystone and quotas<br>
<br>
Regards,<br>
<br>
Tom<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: [Openstack-operators] Delegating quota management for all <br>
projects to a user without the admin role?<br>
Date: Thu, 26 Jan 2017 23:36:10 -0000<br>
From: Edmund Rhudy (BLOOMBERG/ 120 PARK) <erhudy@bloomberg.net><br>
Reply-To: Edmund Rhudy <erhudy@bloomberg.net><br>
To: openstack-operators@lists.openstack.org<br>
<br>
<br>
<br>
I'm looking for a way to allow a user that does not have the admin role <br>
to be able to view and set quota (both Nova/Cinder) for all projects in <br>
an OpenStack cluster. For us, the boundary of a Keystone region is <br>
coterminous with an OpenStack cluster - we don't currently use any sort <br>
of federated Keystone.<br>
<br>
Background: we are involved in a project (not the Keystone variety) for <br>
integrating Bloomberg's internal budget processes closely with <br>
purchasing compute resources. The idea of this system is that you will <br>
purchase some number of standardized compute units and then you can <br>
allocate them to projects in various OpenStack clusters as you wish. In <br>
order to do this, the tool needs to be able to see what Keystone <br>
projects you have access to, see how much quota that project has, and <br>
modify the quota settings for it appropriately.<br>
<br>
For obvious reasons, I'd like to keep the API access for this tool to a <br>
minimum. I know that if all else fails, the goal can be accomplished by <br>
giving it admin access, so I'm keeping that in my back pocket, but I'd <br>
like to exhaust all reasonable options first.<br>
<br>
Allowing the tool to see project memberships and get project information <br>
is easy. The quota part, however, is not. I'm not sure how to accomplish <br>
that delegation, or how to give the tool admin-equivalent access for a <br>
very small subset of the APIs. I'm unfamiliar with Keystone trusts and <br>
am not sure it would be appropriate here anyway, because it would seem <br>
like I'd need to delegate admin control to the role user in order to <br>
allow quota get/set. The only other thing I can think of, and it seems <br>
really off the wall to me, is to:<br>
<br>
* create a local domain in Keystone<br>
* create one user in this local domain per every Keystone project and <br>
add it to that project<br>
* give this user a special role that allows it to set quotas for its project<br>
* set up a massive many-to-one web of trusts where all of these users <br>
are delegated back to the tool's account<br>
<br>
This solution seems very convoluted, and the number of trusts the tool <br>
will need to know about is going to grow linearly with the number of <br>
projects in Keystone.<br>
<br>
The clusters in question are all running Liberty, with Keystone v3 <br>
available. Keystone is in a single-domain configuration, where the <br>
default domain is sourcing users from LDAP and all other information is <br>
stored in SQL.<br>
<br>
Anyone have any thoughts, or am I SOL and just have to give this thing <br>
admin access and make sure the creds stay under lock and key?<br>
</div>
</span></font>
</body>
</html>