Latest revision as of 15:54, 21 June 2013

Make Quantum Authorization Configurable

Please note this specification is still being drafted. Your early feedback is welcome.

High level description

The quantum codebase is now a bit 'polluted' by policy checks spread throughout db logic and sometimes even plugin logic. While per se this is not harmful, it has some drawbacks: 1) There's no uniformity of style in policy.json 2) Understanding how authorization works is not trivial, as the checks might be somewhere else in the code 3) Developers have to explicitly worry about authZ logic, which is mixed with 'business' logic 4) It is hard for users to understand how to tune authZ in their setup by editing policy.json

The aim of this blueprint is therefore to decouple authorization from request processing. We are now in a situation were several policy checks are explicitly performed in the code:

salvatore@ubuntu:~/git/quantum$ find ./quantum/db ./quantum/plugins ./quantum/extensions -name \*.py | xargs grep -n "policy.check" ./quantum/db/l3_db.py:775: return policy.check(context, ./quantum/db/servicetype_db.py:205: return policy.check(context, ./quantum/plugins/nicira/nicira_nvp_plugin/QuantumPlugin.py:806: return policy.check(context, action, resource) ./quantum/plugins/nec/nec_plugin.py:139: return policy.check(context, action, resource) ./quantum/plugins/linuxbridge/lb_quantum_plugin.py:275: return policy.check(context, action, resource) ./quantum/plugins/hyperv/hyperv_quantum_plugin.py:197: return policy.check(context, action, resource) ./quantum/plugins/bigswitch/plugin.py:1233: return policy.check(context, action, resource) ./quantum/plugins/openvswitch/ovs_quantum_plugin.py:347: return policy.check(context, action, resource) ./quantum/plugins/brocade/QuantumPlugin.py:447: return policy.check(context, action, resource) salvatore@ubuntu:~/git/quantum$ find ./quantum/db ./quantum/plugins ./quantum/extensions -name \*.py | xargs grep -n "policy.enforce" ./quantum/db/l3_db.py:320: policy.enforce(context, ./quantum/db/l3_db.py:400: policy.enforce(context, ./quantum/db/l3_db.py:780: return policy.enforce(context, ./quantum/plugins/nicira/nicira_nvp_plugin/QuantumPlugin.py:809: return policy.enforce(context, action, resource) ./quantum/plugins/nec/nec_plugin.py:142: policy.enforce(context, action, resource) ./quantum/plugins/linuxbridge/lb_quantum_plugin.py:278: policy.enforce(context, action, resource) ./quantum/plugins/hyperv/hyperv_quantum_plugin.py:200: policy.enforce(context, action, resource) ./quantum/plugins/bigswitch/plugin.py:1236: policy.enforce(context, action, resource) ./quantum/plugins/openvswitch/ovs_quantum_plugin.py:350: policy.enforce(context, action, resource) ./quantum/extensions/agentscheduler.py:43: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:52: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:61: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:72: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:81: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:92: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:103: policy.enforce(request.context, ./quantum/extensions/agentscheduler.py:114: policy.enforce(request.context,

Resulting in explicit policy actions in policy.json:

"extension:provider_network:view": "rule:admin_only", "extension:provider_network:set": "rule:admin_only", "extension:router:view": "rule:regular_user", "extension:router:set": "rule:admin_only", "extension:router:add_router_interface": "rule:admin_or_owner", "extension:router:remove_router_interface": "rule:admin_or_owner", "extension:port_binding:view": "rule:admin_only", "extension:port_binding:set": "rule:admin_only",

Once this blueprint is implemented, authZ policy processing should either entirely happen in the base controller class, or (see work item list below) be moved into a separate authZ middleware thus making authZ pluggable as well.

Work items

1. 1 - Ensure the policy engine can process authZ for member actions, such as add_router_interface
2. 2 - Allow the policy engine to process also extended resources
3. 3 - Allow the base controller to perform 'view' authZ checking (strip off fields that should not be visibile according to the current rights)
4. 4 - Ensure all extension use the base controller/resource framework (in particular agent extensions)
5. 5 - Move authZ processing from the base controller to a separate middleware in the wsgi pipeline (this might make #4 unnecessary).

Please note that at the moment this blueprint will commit to the first four items as the feasibility of the fifth has not yet been assessed.

API Changes

No Changes

Data Model Changes

No Changes

Policy File Changes

Policy.json will not anymore have 'extension:' rules, which will be replaced by rules like the following:

"create_network:provider:network_type": "rule:admin_only"

Plugin changes

At the end of this blueprint no plugin should have code explicitly checking or enforcing authZ policies