patrole 0.16.0

Team and repository tags

Design Principles

As a Tempest plugin, Patrole borrows some design principles from Tempest design principles, but not all, as its testing scope is confined to policies.

• Stability. Patrole uses OpenStack public interfaces. Tests in Patrole should only touch public OpenStack APIs.

• Atomicity. Patrole tests should be atomic: they should test policies in isolation. Unlike Tempest, a Patrole test strives to only call a single endpoint at a time. This is because it is important to validate each policy is authorized correctly and the best way to do that is to validate each policy alone, to avoid test contamination.

• Complete coverage. Patrole should validate all policy in code defaults. For testing, Patrole uses the API-to-policy mapping contained in each project’s policy in code documentation where applicable.

  For example, Nova’s policy in code documentation is located in the Nova repository under nova/policies. Likewise, Keystone’s policy in code documentation is located in the Keystone repository under keystone/common/policies. The other OpenStack services follow the same directory layout pattern with respect to policy in code.

• Customizable. Patrole should be able to validate custom policy overrides to ensure that those overrides enhance rather than undermine the cloud’s RBAC configuration. In addition, Patrole should be able to validate any role.

• Self-cleaning. Patrole should attempt to clean up after itself; whenever possible we should tear down resources when done.

• Self-testing. Patrole should be self-testing.

Features

• Validation of default policy definitions located in policy.json files.

• Validation of in-code policy definitions.

• Validation of custom policy file definitions that override default policy definitions.

• Built-in positive and negative testing. Positive and negative testing are performed using the same tests and role-switching.

• Valdation of custom roles as well as default OpenStack roles.

How It Works

Patrole leverages oslo.policy (OpenStack’s policy enforcement engine) to determine whether a given role is allowed to perform a policy action, given a specific role and OpenStack service. The output from oslo.policy (the expected result) and the actual result from test execution are compared to each other: if both results match, then the test passes; else it fails.

Quickstart

To run Patrole, you must first have Tempest installed and configured properly. Please reference Tempest_quickstart guide to do so. Follow all the steps outlined therein. Afterward, proceed with the steps below.

1. You first need to install Patrole. This is done with pip after you check out the Patrole repo:

   $ git clone https://opendev.org/openstack/patrole
   $ pip install patrole/

   This can be done within a venv.

2. Next you must properly configure Patrole, which is relatively straightforward. For details on configuring Patrole refer to the Patrole Configuration.

3. Once the configuration is done you’re now ready to run Patrole. This can be done using the tempest_run command. This can be done by running:

   $ tempest run --regex '^patrole_tempest_plugin\.tests\.api'

   There is also the option to use testr directly, or any testr based test runner, like ostestr. For example, from the workspace dir run:

   $ stestr --regex '(?!.*\[.*\bslow\b.*\])(^patrole_tempest_plugin\.tests\.api))'

   will run the same set of tests as the default gate jobs.

   You can also run Patrole tests using tox, but as Patrole needs access to global packages use --sitepackages argument. To do so, cd into the Tempest directory and run:

   $ tox -eall --sitepackages -- patrole_tempest_plugin.tests.api

4. Log information from tests is captured in tempest.log under the Tempest repository. Some Patrole debugging information is captured in that log related to expected test results and Role Overriding.

   More detailed RBAC testing log output is emitted to patrole.log under the Patrole repository. To configure Patrole’s logging, see the Patrole Configuration Guide.

RBAC Tests

To change the roles that the patrole tests are being run as, edit rbac_test_roles in the patrole section of tempest.conf:

[patrole]
rbac_test_roles = member,reader
...

For more information about RBAC, reference the rbac-overview documentation page.

For information regarding which projects Patrole offers RBAC testing for, reference the HACKING documentation page.

Unit Tests

Patrole also has a set of unit tests which test the Patrole code itself. These tests can be run by specifying the test discovery path:

$ stestr --test-path ./patrole_tempest_plugin/tests/unit run

By setting --test-path option to ./patrole_tempest_plugin/tests/unit it specifies that test discovery should only be run on the unit test directory.

Alternatively, there are the py27 and py35 tox jobs which will run the unit tests with the corresponding version of Python.

One common activity is to just run a single test; you can do this with tox simply by specifying to just run py27 or py35 tests against a single test:

$ tox -e py27 -- -n patrole_tempest_plugin.tests.unit.test_rbac_utils.RBACUtilsTest.test_override_role_with_missing_admin_role

Or all tests in the test_rbac_utils.py file:

$ tox -e py27 -- -n patrole_tempest_plugin.tests.unit.test_rbac_utils

You may also use regular expressions to run any matching tests:

$ tox -e py27 -- test_rbac_utils

For more information on these options and details about stestr, please see the stestr documentation.

Release Versioning

Patrole Release Notes shows which changes have been released for each version.

Patrole’s release versioning follows Tempest’s conventions. Like Tempest, Patrole is branchless and uses versioning instead.

Storyboard

Bugs and enhancements are tracked via Patrole’s Storyboard Page.