2023.1 Series Release Notes

3.12.1

Bug Fixes

• Fixed passing --exclude-deprecated boolean value to sphinx-build command. Now --exclude-deprecated is only passed when it is True without bool True/False value.

3.12.0

New Features

• Adds the ability to exclude deprecated policies from generated samples by utilizing the --exclude-deprecated setting when generating YAML example files. The Spinx generator can also be controlled using the exclude_deprecated environment variable. By default, these rules will be included, but operators and projects may not desire these deprecated rules to exist in latest documentation, espescially when considering the number of policy rules projects have made in the Secure RBAC effort.

Bug Fixes

• Fixes handling of deprecated rules when generating sample policy files such that legacy rules are no longer automatically aliased in the resulting output. Previously, the behavior led to operator confusion when attempting to evaluate the output to determine if customized rules were required, as the aliases were always added as active rules. A warning is now also added to the generated output. For more information, please see launchpad bug #1945336.

3.10.1

Other Notes

• Scope check is enforced for all rules, registered ones as well as the ones which are subclasses of the BaseCheck class if rule has scope_types set.

3.10.0

Bug Fixes

• [bug 1943584] If file in policy directory was emptied, rules were not re-calculated. The only workaround was to restart an application. Now rules are re-calculated “on the fly”, without app restart.

3.9.0

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 the Bug# 1914095. Policy engine has bug of modifying the registered rule original object which caused issue when there are multiple policy objects are processing rules in parallel. With this fix. policy engine will make copies of all the registered rules and process 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 compatible way. Refer to this document for details.

Deprecation Notes

• policy_file support for JSON formatted file is deprecated. Use YAML formatted file which will be default in future. Use oslopolicy-convert-json-to-yaml tool to convert the existing JSON to YAML formatted policy file in backward 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 behavior 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 new release format. It will upgrade the deprected policy name with the new name.

1.41.0

New Features

• oslopolicy-checker was 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 standardized. In this case they are being standardized 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 standardized. In this case they are being standardized 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.