Yoga Series Release Notes¶
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 hasscope_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
anddeprecated_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
orDocumentedRuleDefault
that have configured adeprecated_rule
should move thedeprecated_reason
anddeprecated_since
parameters to thisDeprecatedRule
.
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 inoslopolicy-sample-generator
andoslopolicy-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. IfTrue
, 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 theenforce_scope
flag so that you can get the benefits of new defaults andscope_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 parseoslo.context
objects if passed intoenforce()
ascreds
. 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 theoslo_context.context.RequestContext.to_policy_values()
method.
Bug Fixes¶
[bug 1779172] The
enforce()
method now supports the ability to parseoslo.context
objects if passed intoenforce()
ascreds
. 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 theoslo_context.context.RequestContext.to_policy_values()
method.
[bug 1741073] Documentation has been improved to include
oslopolicy-sample-generator
andoslopolicy-list-redundant
usage.
1.37.0¶
Bug Fixes¶
[bug 1773473] The
sphinxext
extension for rendering policy documentation now supportsscope_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 calledenforce_scope
. When set toTrue
, oslo.policy will raise anInvalidScope
exception if the context passed into the enforce method doesn’t match the policy’sscope_types
. IfFalse
, 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 introducingscope_types
for policies used in their service.
1.29.0¶
New Features¶
Add support for custom rule check plugins.
http
andhttps
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.