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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• [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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

• 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

Nouvelles fonctionnalités

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

1.9.0

Autres notes

• Commence à utiliser reno pour la gestion des notes de release