Open ljmcgann opened 5 years ago
It turns out that the concept of an 'openstack administrator' is somewhat fuzzy. The current code may be working as intended (by the keystone devs, at least); this may be an additional layer of oslo policy on top.
This may seem like a dumb question. But since we scope everything by project id and only expect to have one openstack instance anyways, why couldnt we just make a config option to specify admin project_ids. Additionally, why do we need to even expose rest api funcitons with admin funcitonality. Arent the only admin uses the matcher and manager services, which would skip the rest api and work with the business object layer?
That's far from a dumb question. The answer is this: when it comes to limiting REST API usage, the recommended OpenStack way is to use oslo.policy. You're also right in that we may be exposing more functionality than we need to with the REST API, especially when it comes to contract creation. But it can be hard to tell at first, and we can always remove them later.
The important part of all this is scoping by project_id anyway; that's the bit that may have a big impact on the demo.
If an openstack administrator curls to the rest api, they will not be granted administrative privileges. This is an issue with the keystonemiddleware (one which the keystone devs don't even know how to fix). The solution for now is to hardcode is_admin to true for services such as the manager. The database api does not need to be modified.