<div dir="ltr"><br>We have a use case where we'd like to have operators or managers that should be able to view aspects of the OpenStack system but are not full admins so shouldn't be able to make changes (boot, etc).<br>
<br>We're running into a problem where, despite changing the policy.json to allow the "viewer" role to the "compute_extension:hosts" action in nova policy.json, the API still requires admin authority. It turns out you can set the policy to anything you want, as long as it requires admin. (compute_extension:hosts corresponds to the "nova host-list" command.)<br>
<br>There are other operations that we've identified also require admin despite policy, hypervisor-list/compute_extension:hypervisors, hypervisor-uptime. I haven't gone through all OpenStack APIs to see which work and which don't. ('nova list' does not require admin.)<br>
<br>I opened a bug: <a href="https://bugs.launchpad.net/nova/+bug/1168488">https://bugs.launchpad.net/nova/+bug/1168488</a><br><br>Bringing this up on the -dev list to get discussion as to if this is really a bug or intended behavior, and also what a fix might be. I can do the work and submit the changes, but am wondering which direction the community would prefer because I don't want to open up a security exposure.<br>
<br>Potential approaches to fixing, at least compute_extension:hosts:<br>a) change DB function so that doesn't require admin, just context.<br>b) provide a different DB function that doesn't require admin, and is called by REST API handler<br>
c) new REST API/extension to get hosts that allows non-admin<br>d) elevate context in REST API handler before calling the DB function<br><br>- Brant<br><br></div>