Per resource policy control

Problem Description

Current policy control allows us to restrict who can query, list plugins or retrieve facets using the oslo policy engine [1]. Openstack is moving towards supporting more fine-grained controls, and for Searchlight a step in that direction is allowing control over individual resource types. For instance, it might be the case in a given cloud that non-administrative users should not be permitted to search a particular resource type. Longer term this allows us to move towards a model where RBAC is defined by policy control; rather than the hard-coded project-based RBAC we use for each plugin, we might replace or augment it with the typical is_admin_or_owner policy rule employed by projects.

Proposed Change

The proposed change will allow policy.json to include rules for individual plugins. A rule resource:<resource type>:allow will control overall access to a plugin. In addition, allow can be replaced with other actions to allow more precise control. For instance, rules might be:

"default": "",
"resource:OS::Glance::Image:allow": "@",
"resource:OS::Glance::Image:facets": "is_admin:True"
"resource:OS::Nova::Server:query": "!"

A future extension may extend this to support RBAC rule specification through policy. For instance, the following rules might translate into the existing RBAC query we have today:

"admin_or_owner": "is_admin:True or project_id:%(project_id)s",
"resource:OS::Nova::Server:allow": "admin_or_owner",

If a resource is not allowed via policy, it will be removed from the list of types to be searched; if this results in no allowed types, the search will return an empty result set.


Disabling plugins entirely in setup.cfg is one possibility that can be done with the current codebase.

Disabling indexing for non-administrators would require a few changes.

The ideal long-term solution (which is one that this proposal drives towards) is to consume the service policy.json files as does horizon. Ultimately the hard-coded RBAC rules might be expressed as policy rules in many cases, allowing greater configuration flexibility (for instance, restricting access to a resource to the user that created it and not the project/tenant). This will make it easier to keep searchlight deployments in sync with the rules deployed with each service.


[1] Oslo policy documentation: