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:

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

  2. All default policy rules will be available in a standard format to all interested parties, which fulfils the community goal.

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

  4. 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:

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

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

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

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

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

  2. Retire policy enforcement code in monasca-events-api in favour of the policy enforcement module in monasca-common.

  3. Add policy registration code to monasca-api.

  4. Use policy enforcement module in monasca_api.v2.reference.helpers.validate_authorization()

  5. Add policy registration code to monasca-log-api

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

  7. Add monasca-api-policy console script to monasca-api

  8. 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:

  1. Their newly added ability to create policy.json files for Monasca API services

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

Revisions

Release Name

Description

Queens

Introduced