[openstack-dev] view-only use case but APIs are admin-only

Brant Knudson blk at acm.org
Fri Apr 12 22:22:06 UTC 2013

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).

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.)

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.)

I opened a bug: https://bugs.launchpad.net/nova/+bug/1168488

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.

Potential approaches to fixing, at least compute_extension:hosts:
a) change DB function so that doesn't require admin, just context.
b) provide a different DB function that doesn't require admin, and is
called by REST API handler
c) new REST API/extension to get hosts that allows non-admin
d) elevate context in REST API handler before calling the DB function

- Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130412/4b0606f1/attachment.html>

More information about the OpenStack-dev mailing list