Policy Authority Module¶

Overview¶

This module is only called for calculating the “Expected” result if [patrole] test_custom_requirements is False.

Using the Policy Authority Module, policy verification is performed by:

1. Pooling together the default in-code policy rules.
2. Overriding the defaults with custom policy rules located in a policy.json, if the policy file exists and the custom policy definition is explicitly defined therein.
3. Confirming that the policy action – for example, “list_users” – exists. (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”).
4. Performing a call with all necessary data to oslo.policy and returning the expected result back to rbac_rule_validation decorator.

Implementation¶

class patrole_tempest_plugin.policy_authority.PolicyAuthority(project_id, user_id, service, extra_target_data=None)[source]¶

A class that uses oslo.policy for validating RBAC.

__init__(project_id, user_id, service, extra_target_data=None)[source]¶

Initialization of Policy Authority class.

Validates whether a test role can perform a policy action by querying oslo.policy with necessary test data.

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 file by default; its policies are implemented in code and registered as “nova” under “oslo.policy.policies”.

If the policy file is not found in either code or in a policy file, then an exception is raised.

Additionally, if a custom policy file exists along with the default policy in code implementation, the custom policy is prioritized.

Parameters:	project_id (uuid) – project_id of object performing API call user_id (uuid) – user_id of object performing API call service (string) – service of the policy file extra_target_data (dict) – dictionary containing additional object data needed by oslo.policy to validate generic checks

Example:

# Below is the default policy implementation in code, defined in
# a service like Nova.
test_policies = [
    policy.DocumentedRuleDefault(
        'service:test_rule',
        base.RULE_ADMIN_OR_OWNER,
        "This is a description for a test policy",
        [
            {
                'method': 'POST',
                'path': '/path/to/test/resource'
            }
        ]),
        'service:another_test_rule',
        base.RULE_ADMIN_OR_OWNER,
        "This is a description for another test policy",
        [
            {
                'method': 'GET',
                'path': '/path/to/test/resource'
            }
        ]),
]

# Below is the custom override of the default policy in a YAML
# policy file. Note that the default rule is "rule:admin_or_owner"
# and the custom rule is "rule:admin_api". The `PolicyAuthority`
# class will use the "rule:admin_api" definition for this policy
# action.
"service:test_rule" : "rule:admin_api"

# Note below that no override is provided for
# "service:another_test_rule", which means that the default policy
# rule is used: "rule:admin_or_owner".

allowed(rule_name, role)[source]¶

Checks if a given rule in a policy is allowed with given role.

Parameters:	rule_name (string) – Rule to be checked using oslo.policy. is_admin (bool) – Whether admin context is used.

classmethod discover_policy_files()[source]¶

Dynamically discover the policy file for each service in cls.available_services. Pick the first candidate path found out of the potential paths in [patrole] custom_policy_files.

classmethod validate_service(service)[source]¶

Validate whether the service passed to __init__ exists.