Requirements Authority Module

Requirements Authority Module

Overview

Requirements-driven approach to declaring the expected RBAC test results referenced by Patrole. Uses a high-level YAML syntax to crystallize policy requirements concisely and unambiguously.

Note

The Custom Requirements File is required to use this validation approach and, currently, must be manually generated.

This validation approach can be toggled on by setting the [patrole].test_custom_requirements configuration option to True; see Patrole Configuration Guide for more information.

When to use

This RbacAuthority class can be used to achieve a requirements-driven approach to validating an OpenStack cloud’s RBAC implementation. Using this approach, Patrole computes expected test results by performing lookups against a Custom Requirements File which precisely defines the cloud’s RBAC requirements.

Using a high-level declarative language, the requirements are captured unambiguously in the Custom Requirements File, allowing operators to validate their requirements against their OpenStack cloud.

This validation approach should be used when:

  • The cloud has heavily customized policy files that require careful validation against one’s requirements.

    Heavily customized policy files can contain relatively nuanced/technical syntax that impinges upon the goal of using a clear and concise syntax present in the Custom Requirements File to drive RBAC validation.

  • The cloud has non-OpenStack services that require RBAC validation but which don’t leverage the oslo.policy framework.

    Services like Contrail that are present in an OpenStack-based cloud that interface with OpenStack services like Neutron also require RBAC validation. The requirements-driven approach to RBAC validation is framework-agnostic and so can work with any policy engine.

  • Expected results are captured as clear-cut, unambiguous requirements.

    Validating a cloud’s RBAC against high-level, clear-cut requirements is a valid use case. Relying on oslo.policy validating customized policy files is not sufficient to satisfy this use case.

As mentioned above, the trade-off with this approach is having to manually generate the Custom Requirements File. There is currently no tooling to automatically do this.

Custom Requirements File

File path of the YAML file that defines your RBAC requirements. This file must be located on the same host that Patrole runs on. The YAML file should be written as follows:

<service_foo>:
  <api_action_a>:
    - <allowed_role_1>
    - <allowed_role_2>
    - <allowed_role_3>
  <api_action_b>:
    - <allowed_role_2>
    - <allowed_role_4>
<service_bar>:
  <api_action_c>:
    - <allowed_role_3>

Where:

service = the service that is being tested (Cinder, Nova, etc.).

api_action = the policy action that is being tested. Examples:

  • volume:create
  • os_compute_api:servers:start
  • add_image

allowed_role = the oslo.policy role that is allowed to perform the API.

Implementation

class patrole_tempest_plugin.requirements_authority.RequirementsAuthority(filepath=None, component=None)[source]

A class that uses a custom requirements file to validate RBAC.

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 provided requirements file specified by [patrole].custom_requirements_file. Must be a key present in this file, under the appropriate component.
  • role (string) – Role to validate against custom requirements file.
Returns:

True if role is allowed to perform rule_name, else False.

Return type:

bool

Raises:

KeyError – If rule_name does not exist among the keyed policy names in the custom requirements file.

class patrole_tempest_plugin.requirements_authority.RequirementsParser(filepath)[source]

A class that parses a custom requirements file.

class Inner(filepath)[source]
static parse(component)[source]

Parses a requirements file with the following format:

<service_foo>:
  <api_action_a>:
    - <allowed_role_1>
    - <allowed_role_2>
    - <allowed_role_3>
  <api_action_b>:
    - <allowed_role_2>
    - <allowed_role_4>
<service_bar>:
  <api_action_c>:
    - <allowed_role_3>
Parameters:component (str) – Name of the OpenStack service to be validated.
Returns:The dictionary that maps each policy action to the list of allowed roles, for the given component.
Return type:dict
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.