I did some deep excavation and found out that Cinder is specifically the
problem here. With "openstack quota show", it contacts both Nova and Cinder for
quota information. Nova returns successfully, Cinder does not, so the whole
command fails. Nova policy allows structuring things so that an individual user
can manage quota for other users. Cinder, however, is rife with hardcoded
checks for admin privileges at the top-level API. To make things even better,
there's a second layer of hardcoded checks below that on the SQLAlchemy API
that run the same admin privilege checks _again_.
With appropriate policy overrides set, I can see and manage Nova quotas just
fine via novaclient (ignoring Cinder). Unfortunately, we need to be able to
manage volume quotas too, so I'll have to find a different approach (either
that or locally patch some pretty big chunks of Cinder code, which strangely
enough I'd like to avoid).
From: tim.b...@cern.ch
Subject: Re: [Openstack-operators] Delegating quota management for all projects
to a user without the admin role?
I think you could do something with policy.json to define which operations a
given role would have access to. We have used this to provide the centre
operator with abilities such as stop/start. The technical details are
described at
https://openstack-in-production.blogspot.fr/2015/02/delegation-of-roles.html.
Tim
From: "Edmund Rhudy (BLOOMBERG/ 120 PARK)" <erh...@bloomberg.net>
Reply-To: Edmund Rhudy <erh...@bloomberg.net>
Date: Friday, 27 January 2017 at 00:36
To: openstack-operators <openstack-operators@lists.openstack.org>
Subject: [Openstack-operators] Delegating quota management for all projects to
a user without the admin role?
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?
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
