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 result is
True
and the test passes.- Expected result is
False
and the test fails.“Inconsistent” (or failing) cases include:
- Expected result is
False
and the test passes. This results in anRbacOverPermission
exception getting thrown.- Expected result is
True
and the test fails. This results in aForbidden
exception getting thrown.For example, a 200 from the API call and a
True
result fromoslo.policy
or a 403 from the API call and aFalse
result fromoslo.policy
are successful results.
High-level module that implements decorator inside which the “Expected” stage is initiated.
patrole_tempest_plugin.rbac_rule_validation.
action
(service, rule=”, admin_only=False, expected_error_code=403, extra_target_data=None)¶A decorator for verifying policy enforcement.
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
determines whether the test role has sufficient permissions to perform an
API call that enforces the rule
.
The result from _is_authorized
is used to determine the expected
test result. The actual test result is determined by running the
Tempest test this decorator applies to.
Below are the following possibilities from comparing the expected and actual results:
As such, negative and positive testing can be applied using this decorator.
Parameters: |
|
---|---|
Raises: |
|
Examples:
@rbac_rule_validation.action(
service="nova", rule="os_compute_api:os-agents")
def test_list_agents_rbac(self):
# The call to ``switch_role`` is mandatory.
self.rbac_utils.switch_role(self, toggle_rbac_role=True)
self.agents_client.list_agents()
Using the Policy Authority Module, policy verification is performed by:
oslo.policy
otherwise claims that role “foo” is allowed to
perform policy action “bar”, for example, because it defers to the
“default” policy rule and oftentimes the default can be “anyone allowed”).oslo.policy
and returning
the expected result back to rbac_rule_validation
decorator.A class for parsing policy rules into lists of allowed roles.
RBAC testing requires that each rule in a policy file be broken up into the roles that constitute it. This class automates that process.
The list of roles per rule can be reverse-engineered by checking, for each role, whether a given rule is allowed using oslo policy.
Initialization of Rbac Policy Parser.
Parses a policy file to create a dictionary, mapping policy actions to roles. If a policy file does not exist, checks whether the policy file is registered as a namespace under oslo.policy.policies. Nova, for example, doesn’t use a policy.json file by default; its policy is implemented in code and registered as ‘nova’ under oslo.policy.policies.
If the policy file is not found in either place, raises an exception.
Additionally, if the policy file exists in both code and as a policy.json (for example, by creating a custom nova policy.json file), the custom policy file over the default policy implementation is prioritized.
Parameters: |
|
---|
Validate whether the service passed to __init__
exists.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.