A more flexible definition of HIL admin when using Keystone auth

[jeremyfreudberg]

Right now (when HIL is configured to use Keystone auth) a HIL admin is a user with the admin role in Keystone. https://github.com/CCI-MOC/hil/blob/master/hil/ext/auth/keystone.py#L49

For those who are not Keystone experts, some background/clarity can be found here: #615 (comment)

Ideally the definition of HIL admin would be more flexible: the simplest solution is replacing the hard-coded admin role check to instead check for some arbitrary custom role (which could be indicated by the configuration file). This would allow cloud operators to delegate the ability to manage HIL without also delegating any extra privileges which may also be already linked to the admin role.

I'm purposely limiting the scope of this issue: there is a lot more to be said about admin-ness, roles, and policy. We could eventually get fancy with it and support something like oslo.policy.

[zenhack]

I think making the privileged role configurable is a good idea. The patch would be trivial.

[henn]

In theory, I totally agree with this. The "admin" check was a stop-gap until we had something better (which happened to agree with what OpenStack does by default IIRC).

My understanding is that roles in OpenStack services are defined by policies stored in json files.

Is this oslo.policy?

Is there a parser for these json files available via a straightforward library interface?

[jeremyfreudberg]

@henn The JSON-stored policies consumed by OpenStack services are, in fact, oslo.policy -- which serves as both the parser of those files and can act as the enforcer of the policies within the API code.

oslo.policy is powerful - you can define policy not only by Keystone role, but also by membership in Keystone project/domain, being a specific user, etc. And the rules can be combined, and are per-action and per-method.

To quote myself:

I'm purposely limiting the scope of this issue

oslo.policy is great, but it is very OpenStacky (much more than other oslo libraries), since it is so Keystone-oriented. It's a larger discussion as to whether or not it is appropriate to introduce it to HIL. (But we can have that discussion if you want.) I think, start small with just having the single configurable role to determine admin-ness, and then we can move forward as we see fit from there.

[zenhack]

I am very against letting any of this creeping into hil core, though I'm okay making the extension able to be smarter about how it determines admin/project access. I agree we should limit the initial scope though.