Felipe Monteiro | 88a5bab | 2017-08-31 04:00:32 +0100 | [diff] [blame] | 1 | .. _rbac-validation: |
| 2 | |
| 3 | RBAC Testing Validation |
| 4 | ======================= |
| 5 | |
| 6 | -------- |
| 7 | Overview |
| 8 | -------- |
| 9 | |
Felipe Monteiro | f2b58d7 | 2017-08-31 22:40:36 +0100 | [diff] [blame] | 10 | RBAC testing validation is broken up into 3 stages: |
Felipe Monteiro | 88a5bab | 2017-08-31 04:00:32 +0100 | [diff] [blame] | 11 | |
| 12 | 1. "Expected" stage. Determine whether the test should be able to succeed |
| 13 | or fail based on the test role defined by ``[patrole] rbac_test_role``) |
| 14 | and the policy action that the test enforces. |
| 15 | 2. "Actual" stage. Run the test by calling the API endpoint that enforces |
| 16 | the expected policy action using the test role. |
| 17 | 3. Comparing the outputs from both stages for consistency. A "consistent" |
| 18 | result is treated as a pass and an "inconsistent" result is treated |
| 19 | as a failure. "Consistent" (or successful) cases include: |
| 20 | |
| 21 | * Expected result is ``True`` and the test passes. |
| 22 | * Expected result is ``False`` and the test fails. |
| 23 | |
| 24 | "Inconsistent" (or failing) cases include: |
| 25 | |
| 26 | * Expected result is ``False`` and the test passes. This results in an |
| 27 | ``RbacOverPermission`` exception getting thrown. |
| 28 | * Expected result is ``True`` and the test fails. This results in a |
| 29 | ``Forbidden`` exception getting thrown. |
| 30 | |
| 31 | For example, a 200 from the API call and a ``True`` result from |
| 32 | ``oslo.policy`` or a 403 from the API call and a ``False`` result from |
| 33 | ``oslo.policy`` are successful results. |
| 34 | |
| 35 | ------------------------------- |
| 36 | The RBAC Rule Validation Module |
| 37 | ------------------------------- |
| 38 | |
| 39 | High-level module that implements decorator inside which the "Expected" stage |
| 40 | is initiated. |
| 41 | |
| 42 | .. automodule:: patrole_tempest_plugin.rbac_rule_validation |
| 43 | :members: |
Felipe Monteiro | f2b58d7 | 2017-08-31 22:40:36 +0100 | [diff] [blame] | 44 | :private-members: |
Felipe Monteiro | 88a5bab | 2017-08-31 04:00:32 +0100 | [diff] [blame] | 45 | |
| 46 | --------------------------- |
| 47 | The Policy Authority Module |
| 48 | --------------------------- |
| 49 | |
Felipe Monteiro | f2b58d7 | 2017-08-31 22:40:36 +0100 | [diff] [blame] | 50 | Module called by the "RBAC Rule Validation Module" to verify whether the test |
| 51 | role is allowed to execute a policy action by querying ``oslo.policy`` with |
| 52 | required test data. The result is used by the "RBAC Rule Validation Module" as |
| 53 | the `expected` result. |
| 54 | |
| 55 | This module is only called for calculating the `expected` result if |
| 56 | ``[patrole] test_custom_requirements`` is ``False``. |
| 57 | |
Felipe Monteiro | 88a5bab | 2017-08-31 04:00:32 +0100 | [diff] [blame] | 58 | Using the Policy Authority Module, policy verification is performed by: |
| 59 | |
| 60 | 1. Pooling together the default `in-code` policy rules. |
| 61 | 2. Overriding the defaults with custom policy rules located in a policy.json, |
| 62 | if the policy file exists and the custom policy definition is explicitly |
| 63 | defined therein. |
| 64 | 3. Confirming that the policy action -- for example, "list_users" -- exists. |
| 65 | (``oslo.policy`` otherwise claims that role "foo" is allowed to |
| 66 | perform policy action "bar", for example, because it defers to the |
| 67 | "default" policy rule and oftentimes the default can be "anyone allowed"). |
| 68 | 4. Performing a call with all necessary data to ``oslo.policy`` and returning |
| 69 | the expected result back to ``rbac_rule_validation`` decorator. |
| 70 | |
| 71 | .. automodule:: patrole_tempest_plugin.policy_authority |
| 72 | :members: |
| 73 | :special-members: |