Xena Series Release Notes

3.8.3

Bug Fixes

  • Fixes the mapping of ‘system_scope’ to ‘system’ when enforce is called with a ‘creds’ dictionary instead of a RequestContext.

3.7.0

New Features

  • DeprecatedRule now accepts two new parameters: deprecated_reason and deprecated_since. These should be used in place of the equivalent parameters on the rule that is replacing this rule in order to avoid confusion.

Upgrade Notes

  • Users with a RuleDefault or DocumentedRuleDefault that have configured a deprecated_rule should move the deprecated_reason and deprecated_since parameters to this DeprecatedRule.

3.6.2

Bug Fixes

  • This fixes Bug #1914095. Policy engine has a bug of modifying the registered rule original object which caused issue when there are multiple policy objects processing rules in parallel. With this fix. the policy engine will make copies of all the registered rules and process them accordingly.

3.6.1

Bug Fixes

  • [bug 1913718] The Enforcer() object now only processes deprecated rules once at load or enforcement time, improving performance for users that make extensive use of policy enforcement.

3.4.0

New Features

  • Add oslopolicy-convert-json-to-yaml tool to convert the JSON formatted policy file to YAML format in a compatible way. Refer to this document for details.

Deprecation Notes

  • policy_file support for JSON formatted files is deprecated. Use YAML formatted file which will be the default in future. Use oslopolicy-convert-json-to-yaml tool to convert the existing JSON to YAML formatted policy file in a backwards-compatible way.

    JSON format support and --format option in oslopolicy-sample-generator and oslopolicy-policy-upgrade tools are also deprecated. In future release, --format option will be removed.

3.3.0

New Features

  • A new tool, oslopolicy-validator, has been added. It allows deployers to easily run basic sanity checks against their policy files. See the documentation for full details.

3.2.1

Bug Fixes

  • [bug 1880959] The behaviour of policy file reloading from policy directories was fixed. Previously the rules from policy files located in the directories specified in the policy_dirs option were not reapplied after the rules from the primary policy file have been reapplied due to a change.

3.1.0

New Features

  • A new configuration option enforce_new_defaults has been added to the [oslo_policy] group to control whether or not to use the old deprecated defaults. If True, the old deprecated defaults are not going to be evaluated which means if any existing token is allowed for old defaults but disallowed for new defaults it will be disallowed. It is encouraged to enable this flag along with the enforce_scope flag so that you can get the benefits of new defaults and scope_type together. This way operators can switch to new defaults without overwriting the rules in the policy file.

3.0.0

Upgrade Notes

  • Support for Python 2.7 has been dropped. The minimum version of Python now supported is Python 3.6.

2.4.0

Bug Fixes

  • Deprecated policy warnings are now suppressed in the oslopolicy-list-redundant tool so that they don’t overwhelm the relevant output.

2.1.0

New Features

  • Add oslopolicy-policy-upgrade command to help operators upgrade their self-defined policy file to a new release format. It will upgrade the deprecated policy name with the new name.

1.41.0

New Features

  • oslopolicy-checker has added the ability to accept a file containing a hash that represents the target. This makes it possible to check policies that have non-conventional targets such as Barbican.

1.38.1

Bug Fixes

  • As reported in Launchpad bug 1723030, under some circumstances policy checks caused a significant performance degradation. This release includes improved logic around rule validation to prevent that.

1.38.0

New Features

  • [bug 1779172] The enforce() method now supports the ability to parse oslo.context objects if passed into enforce() as creds. This provides more consistent policy enforcement for service developers by ensuring the attributes provided in policy enforcement are standardised. In this case they are being standardised through the oslo_context.context.RequestContext.to_policy_values() method.

Bug Fixes

  • [bug 1779172] The enforce() method now supports the ability to parse oslo.context objects if passed into enforce() as creds. This provides more consistent policy enforcement for service developers by ensuring the attributes provided in policy enforcement are standardised. In this case they are being standardised through the oslo_context.context.RequestContext.to_policy_values() method.

  • [bug 1741073] Documentation has been improved to include oslopolicy-sample-generator and oslopolicy-list-redundant usage.

1.37.0

Bug Fixes

  • [bug 1773473] The sphinxext extension for rendering policy documentation now supports scope_types attributes.

  • [bug 1771442] Policy rules that are deprecated for removal are now properly formatted when rendering sample policy files for documentation.

1.33.0

New Features

  • A new configuration option has been added to the [oslo_policy] group called enforce_scope. When set to True, oslo.policy will raise an InvalidScope exception if the context passed into the enforce method doesn’t match the policy’s scope_types. If False, a warning will be logged for operators. Note that operators should only enable this option once they’ve audited their users to ensure system users have roles on the system. This could potentially prevent some users from being able to make system-level API calls. This will also give other services the flexibility to fix long-standing RBAC issues in OpenStack once they start introducing scope_types for policies used in their service.

1.29.0

New Features

  • Add support for custom rule check plugins. http and https external rule checks have been converted into stevedore plugins and serve as examples.

1.22.1

New Features

  • Added the option to define a more descriptive policy rule by using policy.DocumentedRuleDefault class. When using this class it is required that the description and operations parameters are defined, unlike policy.RuleDefault. The operations parameter is a list of dictionaries that must contain the two keys ‘path’ and ‘method’ which represent the API URL and the HTTP REQUEST METHOD. More information can be found in the policy usage documentation.

1.15.0

New Features

  • Add sphinxpolicygen Sphinx plugin, which can be used to generate a sample policy file for use in documentation.

1.9.0

Other Notes

  • Switch to reno for managing release notes.