[docs] Fix weird indentation in documentation

This commit fixes weird indentations in the documentation. And this
commit also adds auto generated file `patrole.conf.sample` to
.gitignore because we don't need to manage it in a git repository.

Change-Id: Ic6816ad04675917bf81c9d172b09feb5f40a2829
This commit is contained in:
Masayuki Igawa 2018-01-09 17:00:45 +09:00
parent c5f039645d
commit 80b9aab769
No known key found for this signature in database
GPG Key ID: 290F53EDC899BF89
4 changed files with 36 additions and 33 deletions

1
.gitignore vendored
View File

@ -44,6 +44,7 @@ output/*/index.html
# Sphinx
doc/build
doc/source/_static/patrole.conf.sample
# pbr generates these
AUTHORS

View File

@ -7,32 +7,32 @@ Overview
RBAC testing validation is broken up into 3 stages:
#. "Expected" stage. Determine whether the test should be able to succeed
or fail based on the test role defined by ``[patrole] rbac_test_role``)
and the policy action that the test enforces.
#. "Actual" stage. Run the test by calling the API endpoint that enforces
the expected policy action using the test role.
#. Comparing the outputs from both stages for consistency. A "consistent"
result is treated as a pass and an "inconsistent" result is treated
as a failure. "Consistent" (or successful) cases include:
#. "Expected" stage. Determine whether the test should be able to succeed
or fail based on the test role defined by ``[patrole] rbac_test_role``)
and the policy action that the test enforces.
#. "Actual" stage. Run the test by calling the API endpoint that enforces
the expected policy action using the test role.
#. Comparing the outputs from both stages for consistency. A "consistent"
result is treated as a pass and an "inconsistent" result is treated
as a failure. "Consistent" (or successful) cases include:
* Expected result is ``True`` and the test passes.
* Expected result is ``False`` and the test fails.
* Expected result is ``True`` and the test passes.
* Expected result is ``False`` and the test fails.
For example, a 200 from the API call and a ``True`` result from
``oslo.policy`` or a 403 from the API call and a ``False`` result from
``oslo.policy`` are successful results.
For example, a 200 from the API call and a ``True`` result from
``oslo.policy`` or a 403 from the API call and a ``False`` result from
``oslo.policy`` are successful results.
"Inconsistent" (or failing) cases include:
"Inconsistent" (or failing) cases include:
* Expected result is ``False`` and the test passes. This results in an
``RbacOverPermission`` exception getting thrown.
* Expected result is ``True`` and the test fails. This results in a
``Forbidden`` exception getting thrown.
* Expected result is ``False`` and the test passes. This results in an
``RbacOverPermission`` exception getting thrown.
* Expected result is ``True`` and the test fails. This results in a
``Forbidden`` exception getting thrown.
For example, a 200 from the API call and a ``False`` result from
``oslo.policy`` or a 403 from the API call and a ``True`` result from
``oslo.policy`` are failing results.
For example, a 200 from the API call and a ``False`` result from
``oslo.policy`` or a 403 from the API call and a ``True`` result from
``oslo.policy`` are failing results.
-------------------------------
The RBAC Rule Validation Module

View File

@ -43,15 +43,15 @@ def action(service, rule='', admin_only=False, expected_error_code=403,
A decorator which allows for positive and negative RBAC testing. Given:
* an OpenStack service,
* a policy action (``rule``) enforced by that service, and
* the test role defined by ``[patrole] rbac_test_role``
* an OpenStack service,
* a policy action (``rule``) enforced by that service, and
* the test role defined by ``[patrole] rbac_test_role``
determines whether the test role has sufficient permissions to perform an
API call that enforces the ``rule``.
This decorator should only be applied to an instance or subclass of
``tempest.test.BaseTestCase``.
``tempest.test.BaseTestCase``.
The result from ``_is_authorized`` is used to determine the *expected*
test result. The *actual* test result is determined by running the
@ -306,14 +306,14 @@ def _format_extra_target_data(test_obj, extra_target_data):
Before being formatted, "extra_target_data" is a dictionary that maps a
policy string like "trust.trustor_user_id" to a nested list of
``tempest.test.BaseTestCase`` attributes. For example, the attribute list
in:
in::
"trust.trustor_user_id": "os.auth_provider.credentials.user_id"
"trust.trustor_user_id": "os.auth_provider.credentials.user_id"
is parsed by iteratively calling ``getattr`` until the value of "user_id"
is resolved. The resulting dictionary returns:
is resolved. The resulting dictionary returns::
"trust.trustor_user_id": "the user_id of the `os_primary` credential"
"trust.trustor_user_id": "the user_id of the `os_primary` credential"
:param test_obj: An instance or subclass of ``tempest.test.BaseTestCase``.
:param extra_target_data: Dictionary, keyed with ``oslo.policy`` generic

View File

@ -68,8 +68,9 @@ class RbacUtils(object):
"""Override the role used by ``os_primary`` Tempest credentials.
Temporarily change the role used by ``os_primary`` credentials to:
* ``[patrole] rbac_test_role`` before test execution
* ``[identity] admin_role`` after test execution
* ``[patrole] rbac_test_role`` before test execution
* ``[identity] admin_role`` after test execution
Automatically switches to admin role after test execution.
@ -111,8 +112,9 @@ class RbacUtils(object):
"""Switch the role used by `os_primary` Tempest credentials.
Switch the role used by `os_primary` credentials to:
* admin if `toggle_rbac_role` is False
* `CONF.patrole.rbac_test_role` if `toggle_rbac_role` is True
* admin if `toggle_rbac_role` is False
* `CONF.patrole.rbac_test_role` if `toggle_rbac_role` is True
:param test_obj: test object of type tempest.lib.base.BaseTestCase
:param toggle_rbac_role: role to switch `os_primary` Tempest creds to