v0.5.0 Release Notes

0.5.0 Release Notes

0.5.0

Prelude

This release is to tag the Patrole for OpenStack Stein release. After this release, Patrole will support below OpenStack Releases:

  • Stein

  • Rocky

  • Queens

  • Pike

Current development of Patrole is for OpenStack Train development cycle. Every Patrole commit is also tested against master during the Train cycle. However, this does not necessarily mean that using Patrole as of this tag will work against a Train (or future release) cloud.

New Features

  • The exception class RbacMalformedException has been broken up into the following discrete exceptions:

    • RbacMissingAttributeResponseBody - incomplete means that the response body (for show or list) is missing certain attributes

    • RbacPartialResponseBody - partial means that a list response only returned a subset of the possible results available.

    • RbacEmptyResponseBody - empty means that the show or list response body is entirely empty

    Each of the exception classes above deals with a different type of failure related to a soft authorization failure. This means that, rather than a 403 error code getting returned by the server, the response body is incomplete in some way.

  • Add new exception called RbacOverrideRoleException. Used for safeguarding against false positives that might occur when the expected exception isn’t raised inside the override_role context. Specifically, when:

    • override_role isn’t called

    • an exception is raised before override_role context

    • an exception is raised after override_role context

  • Supporting the role inference rules API gives Patrole an ability of testing role chains, when one role implies the second which can also imply the third:

    admin implies member implies reader

    Now in a case of testing against an admin role ([patole] rbac_test_roles = admin) the rbac_rule_validation.action calls the rbac_utils.get_all_needed_roles function to extend the roles and validates a policy rule against the full list of possible roles:

    [“admin”, “member”, “reader”]

    Here is few examples:

    [“admin”] >> [“admin”, “member”, “reader”] [“member”] >> [“member”, “reader”] [“reader”] >> [“reader”] [“custom_role”] >> [“custom_role”] [“custom_role”, “member”] >> [“custom_role”, “member”, “reader”]

  • We have replaced CONF.patrole.rbac_test_role with CONF.patrole.rbac_test_roles, where instead of single role we can specify list of roles to be assigned to test user. This way we may run rbac tests for scenarios that requires user to have more that a single role.

  • In order to implement the tests for plugins which do not maintain the policy.json with full list of the policy rules and provide policy file with only their own policy rules, the Patrole should be able to load and merge multiple policy files for any of the services.

    • Discovery all policy files for each of the services. The updated discover_policy_files function picks all candidate paths found out of the potential paths in the [patrole].custom_policy_files config option. Using glob.glob() function makes it possible to use the patterns like ‘*.json’ to discover the policy files.

    • Loading and merging a data from multiple policy files. Patrole loads a data from each of the discovered policy files for a service and merge the data from all files.

  • In order to test the list actions which doesn’t have its own policy, implemented the override_role_and_validate_list function. The function has two modes:

    • Validating the number of the resources in a ResponseBody before calling the override_role and after.

      # make sure at least one resource is available
      self.ntp_client.create_policy_dscp_marking_rule()
      # the list of resources available for a user with admin role
      admin_resources = self.ntp_client.list_dscp_marking_rules(
          policy_id=self.policy_id)["dscp_marking_rules"]
      with self.rbac_utils.override_role_and_validate_list(
              self, admin_resources=admin_resources) as ctx:
          # the list of resources available for a user with member role
          ctx.resources = self.ntp_client.list_dscp_marking_rules(
              policy_id=self.policy_id)["dscp_marking_rules"]
      
    • Validating that a resource, created before override_role, is not present in a ResponseBody.

      # the resource created by a user with admin role
      admin_resource_id = (
          self.ntp_client.create_dscp_marking_rule()
          ["dscp_marking_rule"]["id'])
      with self.rbac_utils.override_role_and_validate_list(
              self, admin_resource_id=admin_resource_id) as ctx:
          # the list of resources available for a user wirh member role
          ctx.resources = self.ntp_client.list_dscp_marking_rules(
              policy_id=self.policy_id)["dscp_marking_rules"]
      
  • Merged RbacUtils and RbacUtilsMixin classes. Now there is only RbacUtilsMixin class. The new class still provides all functionality of the original RbacUtils class. New implementation simplifies the usage of the rbac utils:

    • there is no need in calling cls.setup_rbac_utils() function, because it happens automatically at the setup_clients step.

    • there is no rbac_utils variable, so if you need to call a override_role function, just do it using self:

      with self.override_role():
          ...
      
    • there is no need in test_obj variable for override_role function, because it can use self.

  • A new policy feature flag called [policy_feature_flag].removed_nova_policies_stein has been added to Patrole’s config to handle Nova API extension policies removed in Stein.

    The policy feature flag is applied to tests that validate response bodies for expected attributes previously returned for the following policies that passed authorization:

    • os_compute_api:os-config-drive

    • os_compute_api:os-extended-availability-zone

    • os_compute_api:os-extended-status

    • os_compute_api:os-extended-volumes

    • os_compute_api:os-keypairs

    • os_compute_api:os-server-usage

    • os_compute_api:os-flavor-rxtx

    • os_compute_api:os-flavor-access (only from /flavors APIs)

    • os_compute_api:image-size

    Note that not all removed policies are included above because test coverage is missing for them (like os_compute_api:os-security-groups).

  • Added new feature flag called removed_keystone_policies_stein under the configuration group [policy-feature-enabled] for skipping Keystone tests whose policies were removed in Stein. This feature flag is currently applied to credentials-related policies, e.g.: identity:[create|update|get|delete]_credential

  • The requirements_authority module now supports the following 3 cases:

    • logical or operation of roles (existing functionality)

    • logical and operation of roles (new functionality)

    • logical not operation of roles (new functionality)

    <service_foo>:
      <logical_or_example>:
        - <allowed_role_1>
        - <allowed_role_2>
      <logical_and_example>:
        - <allowed_role_3>, <allowed_role_4>
    <service_bar>:
      <logical_not_example>:
        - <!disallowed_role_5>
    

    Each item under logical_or_example is “logical OR”-ed together. Each role in the comma-separated string under logical_and_example is “logical AND”-ed together. And each item prefixed with “!” under logical_not_example is “logical negated”.

    This allows for expressing many more complex cases using the requirements_authority YAML syntax. For example, the policy rule (i.e. what may exist in a policy.yaml file):

    "foo_rule: (role:a and not role:b) or role:c"
    

    May now be expressed using the YAML syntax as:

    foo_rule:
        - a, !b
        - c
    
  • Patrole will validate the deprecated policy rules (if applicable) alongside the current policy rule. Add [patrole] validate_deprecated_rules enabled by default to validate the deprecated rules.

  • Added new Cinder feature flag (CONF.policy_feature_enabled.added_cinder_policies_stein) for the following newly introduced granular Cinder policies:

    • volume_extension:volume_type_encryption:create

    • volume_extension:volume_type_encryption:get

    • volume_extension:volume_type_encryption:update

    • volume_extension:volume_type_encryption:delete

    The corresponding Patrole test cases are modified to support the granularity. The test cases also support backward compatibility with the old single rule: volume_extension:volume_type_encryption

    The rules parameter in rbac_rule_validation.action decorator now also accepts a list of callables; each callable should return a policy action (str).

  • Patrole now supports parsing custom YAML policy files, the new policy file extension since Ocata. The function _get_policy_data has been renamed to get_rules and been changed to re-use oslo_policy.policy.Rules.load function.

Upgrade Notes

  • The exception class RbacMalformedException has been removed. Use one of the following exception classes instead:

    • RbacMissingAttributeResponseBody

    • RbacPartialResponseBody

    • RbacEmptyResponseBody

  • Remove usage of cls.setup_rbac_utils() function.

  • Remove usage of self.rbac_utils variable:

    with self.rbac_utils.override_role(self):
    

    convert to

    with self.override_role():
    
  • Remove test_obj in usage of override_role context manager:

    with self.override_role(self):
    

    convert to

    with self.override_role():
    
  • Remove deprecated [patrole].enable_rbac configuration option. To skip Patrole tests going forward, use an appropriate regex.

  • The following deprecated parameters in rbac_rule_validation.action decorator:

    • rule

    • expected_error_code

    have been removed. Use the non-deprecated versions instead:

    • rules

    • expected_error_codes

Deprecation Notes

  • Patrole will only support the v3 Tempest roles client for role overriding operations. Support for the v2 version has been dropped because the Keystone v2 API is slated for removal.

  • Config parameter CONF.rbac_test_role is deprecated in favor of CONF.rbac_test_roles that implements a list of roles instead of single role.

Bug Fixes

  • Previously, the rbac_rule_validation.action decorator could catch expected exceptions with no regard to where the error happened. Such behavior could cause false-positive results. To prevent this from happening from now on, if an exception happens outside of the override_role context, it will cause rbac_exceptions.RbacOverrideRoleException to be raised.