| Felipe Monteiro | 443d39c | 2018-04-08 17:05:33 -0400 | [diff] [blame] | 1 | .. _rbac_field_guide: |
| 2 | |
| 3 | Patrole Field Guide to RBAC Tests |
| 4 | ================================= |
| 5 | |
| 6 | |
| 7 | What are these tests? |
| 8 | --------------------- |
| 9 | |
| 10 | Patrole's primary responsibility is to ensure that your OpenStack cloud |
| 11 | has properly configured Role-Based Access Control (RBAC). All Patrole |
| 12 | tests cases are devoted to this responsibility. Tempest API clients |
| 13 | and utility functions are leveraged to accomplish this goal, but such |
| 14 | functionality is secondary to RBAC validation. |
| 15 | |
| 16 | Like Tempest, Patrole not only tests expected positive paths for RBAC |
| 17 | validation, but also -- and more importantly -- negative paths. While |
| 18 | Patrole could be thought of as validating RBAC, it more importantly |
| 19 | verifies that your OpenStack cloud is secure from the perspective of |
| 20 | RBAC (there are many gotchas when it comes to security, not just RBAC). |
| 21 | |
| 22 | Negative paths are arguably more important than positive paths when it |
| 23 | comes to RBAC and by extension security, because it is essential that |
| 24 | your cloud be secure from unauthorized access. For example, while it is |
| 25 | important to verify that the admin role has access to admin-level |
| 26 | functionality, it is of critical importance to verify that non-admin roles |
| 27 | *do not* have access to such functionality. |
| 28 | |
| 29 | Unlike Tempest, Patrole accomplishes negative testing implicitly -- by |
| 30 | abstracting it away in the background. Patrole dynamically determines |
| 31 | whether a role should have access to an API depending on your cloud's |
| 32 | policy configuration and then confirms whether that is true or false. |
| 33 | |
| 34 | |
| 35 | Why are these tests in Patrole? |
| 36 | ------------------------------- |
| 37 | |
| 38 | These tests constitute the core mission in Patrole: to verify RBAC. These |
| 39 | tests are mainly intended to validate RBAC, but can also *unofficially* |
| 40 | be used to discover the policy-to-API mapping for an OpenStack component. |
| 41 | |
| 42 | It could be argued that some of these tests could be implemented in |
| 43 | the projects themselves, but that approach has the following shortcomings: |
| 44 | |
| 45 | * The projects do not validate RBAC from an integration testing perspective. |
| 46 | * By extension, RBAC across cross-service communication is not usually |
| 47 | validated. |
| 48 | * The projects' tests do not pass all the metadata to ``oslo.policy`` that is |
| 49 | in reality passed by the deployed server to that library to determine |
| 50 | whether a given user is authorized to perform an API action. |
| 51 | * The projects do not exhaustively do RBAC testing for all positive and |
| 52 | negative paths. |
| 53 | * Patrole is designed to work with any role via configuration settings, but |
| 54 | on the other hand the projects handpick which roles to test. |
| 55 | |
| 56 | |
| 57 | Scope of these tests |
| 58 | -------------------- |
| 59 | |
| 60 | RBAC tests should always use the Tempest implementation of the |
| 61 | OpenStack API, to take advantage of Tempest's stable library. |
| 62 | |
| 63 | Each test should test a specific API endpoint and the related policy. |
| 64 | |
| 65 | Each policy should be tested in isolation of one another -- or at least |
| 66 | as close to this rule as possible -- to ensure proper validation of RBAC. |
| 67 | |
| 68 | Each test should be able to work for positive and negative paths. |
| 69 | |
| 70 | All tests should be able to be run on their own, not depending on the |
| 71 | state created by a previous test. |