Use policies for authZ in placement API

Registered by Chris Dent

At the end of Newton, the placement API was released with the most simple of authorization handling: For any resource other than the discovery document at '/' the requesting user has to have the role 'admin'. This is done by directly checking the 'roles' in the context provided in environ.

For the long term this provides insufficient granularity. While some operations in the placement API will require elevated privileges, not all will. Therefore we should implement policy enforcement in the placement API using a version of the 'context.can' idiom used throughout nova.

Given the granularity of the handler methods in the placement API it is likely that it will be possible to do the majority of this handling using a decorator on the handlers themselves.

Ideally this will be done in a way that doesn't require a policy file, but can use one if required. There should be reasonable defaults from the outset, based on the current functionality. We may wish to consider disallowing the use of a file if there's no reason to ever customize access.

Blueprint information

Status:
Complete
Approver:
Matt Riedemann
Priority:
Medium
Drafter:
Chris Dent
Direction:
Approved
Assignee:
Chris Dent
Definition:
Approved
Series goal:
Accepted for ocata
Implementation:
Implemented
Milestone target:
milestone icon ocata-3
Started by
Matt Riedemann
Completed by
Matt Riedemann

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/placement-api-policy-authz,n,z

Addressed by: https://review.openstack.org/382640
    Replace admin check with policy check in placement API

The initial change adds the global policy check which we can build on later if needed. This specless blueprint is approved after the fact. -- mriedem 20161115

With the initial change in https://review.openstack.org/382640 we have a basic framework for doing policy rule checking in the placement API, and by default we're using admin-only for all routes, hard-coded. There is nothing in the near-term for Ocata that looks like it's going to require adjusting the policy, so adding that support/flexibility in could be a later separate blueprint. I'm closing this for Ocata. -- mriedem 20161228

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.