Open Stack

Hi All,

This thread is to request the neutron team on review help for neutron policy testing in Patrole project.

Folks who are not familiar with Patrole, below is the  brief background & description of  Patrole:
-------------------------
OpenStack Patrole is official project under QA umbrella which perform the RBAC testing. It has been in development state since Ocata and currently released its 0.4.0 version for Rocky[1]. Complete Documentation can be found here[2]. #openstack-qa is IRC channel for Patrole. 

Main goal of this project is to perform the RBAC testing for OpenStack where we will first focus on  Nova, Cinder, Keystone, Glance and Neutron in Patrole repo and provide the framework / mechanism  to extend the testing for other project via plugin or some other way (yet to finalized). 

Current state :
- Good coverage for Nova, Keystone, Cinder, Glance.
- Ongoing 1. neutron coverage, framework stability
- Next 1. stable release of Patrole, 2. start gating the Patrole testing on project side.
--------------------------

Patrole team is working on neutron policy testing. As you know neutron policy is not as simple as other projects and also no user facing documentation for policy. I was discussing with amotoki about it and got to know that he is working on policy doc or something which can be useful for users and so does Patrole can consume that for writing the test cases.

Another request QA has for neutron team is about review the neutron policy test cases. Here is the complete review list[3] (cannot get the single gerrit topic linked with story#) and it will be great if neutron team can keep eyes on those and provide early feedback on new test cases (their policy name, return code, coverage etc). 

One example where we need feedback is - https://review.openstack.org/#/c/586739/ 

Q: What is the return code for GET API if policy authorization fail. 

>From neutron doc [4] (though it is internal doc but it explain the neutron policy internals), it seems for GET, PUT, DELETE where resource existence is checked first. If resource does not exist then 404 is return for security purpose as 403 can tell invalid user that this resource exist. 

But for PUT and DELETE, it can be 403 when resource exist but user does not have access to PUT/DELETE operation. 

I was discussing it with amotoki also and we thought of
 - Check 404 for GET 
 - Check [403, 404] for PUT and DELETE.
 - later we will strict the checks of 404 and 403 separately for PUT and DELETE.

Let's us know if that is right way to proceed. 

[1] https://docs.openstack.org/releasenotes/patrole/v0.4.0.html  
[2] https://docs.openstack.org/patrole/latest/ 
[3] https://storyboard.openstack.org/#!/story/2002641
[4] https://docs.openstack.org/neutron/pike/contributor/internals/policy.html#request-authorization

-gmann