Add spec on implementing oslo.policy

Presently, neither monasca-api nor monasca-log-api use oslo.policy. Instead,
they contain their own policy enforcement code. Without oslo.policy they will
not be able to implement the policy in code community goal for Queens, which
requires the use of oslo mechanisms for defining and enforcing policy. This
spec gives a roadmap for switching monasca-{api,log-api} to using oslo.policy.

Change-Id: Icf9ec728a20ff38cfe29c72acae2df5f4383f0f6
Story: 2001233
Task: 5749
This commit is contained in:
Johannes Grassler 2017-10-11 15:54:13 +02:00 committed by Amir Mofakhar
parent d8832c9690
commit 921482e249
1 changed files with 224 additions and 0 deletions

View File

@ -0,0 +1,224 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
================================
Use oslo.policy for Monasca APIs
================================
https://storyboard.openstack.org/#!/story/2001233
Presently, neither monasca-api nor monasca-log-api use `oslo.policy`. Instead,
they contain their own policy enforcement code. Without `oslo.policy` they will
not be able to implement the policy in code community goal for Queens[0], which
requires the use of oslo mechanisms for defining and enforcing the policy.
Problem description
===================
Since neither monasca-api nor monasca-log-api use oslo.policy for policy
enforcement, they cannot describe their policy in code using `oslo.policy`
mechanisms as mandated by the community goal[0].
Use Cases
---------
The change proposed by this spec will improve the situation outlined above as
follows:
#. Policy will be enforced in the OpenStack wide standard manner by
`oslo.policy`. This reduces the maintenance burden on Monasca developers
because they will no longer need to maintain Monasca's own policy enforcement
code.
#. All default policy rules will be available in a standard format to all
interested parties, which fulfils the community goal.
#. Operators will be able to override the Monasca API and Monasca Log API
default policies using `policy.json` files and run command line tools to
generate a full `policy.json` for either service (e.g. for auditing
purposes).
#. The ability to use new tooling in oslo.policy that let's developers
deprecate or change policy defaults in a way operators can consume.
Proposed change
===============
This spec proposes the following changes to `monasca-common`, `monasca-api`,
`monasca-log-api` and the upcoming `monasca-events-api`:
#. Implement a policy enforcement engine in `monasca_common.policy`. We can
probably model this on Nova's policy enforcement engine[1]. We will have to
modify it somewhat to account for the fact that we have multiple APIs that
use the same policy engine.
#. Define a module that contains the default policy rules in both `monasca-api`
and `monasca-log-api` and exposes them to the enforcement engine (in
`monasca-events-api` there is such a module already). Nova's approach of
having a `list_rules()` method[2] should work just fine for us.
We can either copy Nova's approach of aggregating individual endpoints'
policies in that central module[3] or just have them in there directly.
#. Modify existing policy enforcement code in `monasca-api`, `monasca-log-api`
and `monasca-events-api` by code to use the enforcement engine from
`monasca-common`.
#. Add monasca-api-policy and monasca-log-api-policy command line entry points
that allow the user to generate a policy.json file for both APIs.
Alternatives
------------
None, since this is a community goal. One thing that could be done differently
is the policy enforcement engine: it would be conceivable to have independent
enforcer implementations in both monasca-api and monasca-log-api. This would
needlessly violate the DRY principle, though.
Data model impact
-----------------
This change does not impact the data model.
REST API impact
---------------
This change must be implemented in a way that creates no discernible impact for
the API's consumers.
Client impact
-------------
N/A
Configuration changes
---------------------
This change will continue to use the same `monasca-api` and `monasca-log-api`
configuration settings we already use for policy enforcement:
* `agent_authorized_roles`, `default_authorized_roles`,
`delegate_authorized_roles` and `read_only_authorized_roles` for `monasca-api`
* `default_roles`, `agent_roles` and `delegate_roles` for `monasca-log-api`
The only difference is that a different implementation
(`monasca-common.policy`) will use them now.
Additionally, the policy enforcer will allow operators to create a
`policy.json` file for each API service that overrides the in-code defaults.
Security impact
---------------
This change introduces a way for operators to influence monasca-api and
monasca-log-api policy through configuration files. If they misconfigure policy
that way, they may allow unauthorized users to send or retrieve metrics and
logs.
Other end user impact
---------------------
N/A
Performance Impact
------------------
N/A
Other deployer impact
---------------------
N/A
Developer impact
----------------
Developers that introduce new API operations will need to register policy rules
for these endpoints once this feature is implemented.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
amofakhar
Work Items
----------
#. Add policy enforcement module to `monasca-common`. It might be a good idea
to have an extension mechanism for the policy's target analogous to this
one[1] in Magnum to account for the different role variables from the
configuration file needed by `monasca-api` and `monasca-log-api`,
respectively. That way a generic policy enforcer can be made flexible to the
point where all the role differences between `monasca-api` and
`monasca-log-api` can be expressed in terms of policy rules.
#. Retire policy enforcement code in `monasca-events-api` in favour of the
policy enforcement module in `monasca-common`.
#. Add policy registration code to `monasca-api`.
#. Use policy enforcement module in `monasca_api.v2.reference.helpers.validate_authorization()`
#. Add policy registration code to `monasca-log-api`
#. Remove policy enforcement code from `monasca_log_api.middleware.role_middleware.`
(for validating agent role) and `monasca_log_api.app.base.request`
and replace it by using `monasca-common.policy` from either
`monasca_log_api.middleware.role_middleware.` or
`monasca_log_api.app.base_request` (to have centralized enforcement in one
spot).
#. Add `monasca-api-policy` console script to `monasca-api`
#. Add `monasca-log-api-policy` console script to `monasca-log-api`
Dependencies
============
N/A
Testing
=======
Existing policy enforcement tests are likely to need a major overhaul.
Documentation Impact
====================
The following things need to be documented for operators:
#. Their newly added ability to create `policy.json` files for Monasca API services
#. The functionality of the `monasca-api-policy` and `monasca-log-api-policy` scripts
References
==========
[0] https://governance.openstack.org/tc/goals/queens/policy-in-code.html
[1] https://github.com/openstack/nova/blob/master/nova/policy.py
[2] https://github.com/openstack/nova/blob/master/nova/policy.py#L207
[3] https://github.com/openstack/nova/blob/master/nova/policies/__init__.py
[2] https://github.com/openstack/magnum/blob/master/magnum/common/policy.py#L102
History
=======
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - Queens
- Introduced