Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: I843745a6763b314ea6a3e861f7fe955008c62b36
Add file to the reno documentation build to show release notes for
stable/2023.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2023.2.
Sem-Ver: feature
Change-Id: Iaf095e2f590862385446bec03dc7a78d067b0237
Add file to the reno documentation build to show release notes for
stable/2023.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2023.1.
Sem-Ver: feature
Change-Id: I279a3b56f331ad2dcafd624f0d8ea166713a58c5
Add file to the reno documentation build to show release notes for
stable/zed.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/zed.
Sem-Ver: feature
Change-Id: Ib8774b60b82602c4a22c622ebe623e348d0f1f2d
The '--exclude-deprecated' parameter should only be passed to
oslo.config to parse when it is True.
The final generated sphinx syntax is[1] where [--exclude-deprecated]
doesn't require True/False value and only should be passed when True.
The change introducing this[2] causes parsing issue in oslo.config[3]
while checking <bool>.startswith (we pass True/False value) and even
after that while calling argparse[4] with following error[5].
[1] usage: sphinx-build [-h] [--config-dir DIR] [--config-file PATH] [--exclude-deprecated] [--format FORMAT] [--namespace NAMESPACE]
[--noexclude-deprecated] [--output-file OUTPUT_FILE]
[2] https://review.opendev.org/c/openstack/oslo.policy/+/830514
[3] https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2937
[4] https://opendev.org/openstack/oslo.config/src/branch/master/oslo_config/cfg.py#L2960
[5] > /usr/lib/python3.8/argparse.py(1781)parse_args()
-> if argv:
(Pdb)
> /usr/lib/python3.8/argparse.py(1782)parse_args()
-> msg = _('unrecognized arguments: %s')
(Pdb)
> /usr/lib/python3.8/argparse.py(1783)parse_args()
-> self.error(msg % ' '.join(argv))
(Pdb)
TypeError: sequence item 0: expected str instance, bool found
> /usr/lib/python3.8/argparse.py(1783)parse_args()
-> self.error(msg % ' '.join(argv))
Handler <function generate_sample at 0x7fc0d6697d30> for event 'builder-inited' threw an exception (exception: sequence item 0: expected str instance, bool found)
Closes-Bug: #1970725
Change-Id: I95745b8d1cbdb6a7cf442d431a998b7e3ff600e4
Add file to the reno documentation build to show release notes for
stable/yoga.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/yoga.
Sem-Ver: feature
Change-Id: I35de33c2f540ceb76b0b12da5373545c15306f6d
Deprecated rules can be confusing and downright unfriendly when
evaluating a generated sample output and seeing legacy rules being
aliased to new rules. Technically this is also invalid and results
in a broken sample file with overriding behavior.
Under normal circumstances, this wouldn't be a big deal, but with
the Secure RBAC effort, projects also performed some further
delineation of RBAC policies instead of performing a 1:1 mapping.
As a result of the policy enforcement model, a prior deprecated
rule was required, which meant the prior deprecated rule would
be reported multiple times in the output.
Since we don't have an extra flag in the policy-in-code definitions
of policies, all we can *really* do is both clarify the purpose
and meaning of the entry, not enable the alias by default in
sample output (as it is a sample! not an override of code!),
and provide projects as well as operators with a knob to
exclude deprecated policy inclusion into examples and sample
output.
Closes-Bug: #1945336
Change-Id: I6d02eb4d8f94323a806fab991ba2f1c3bbf71d04
Previously it was checked only for registered rules but not for
rules which are subclasses of the BaseCheck class.
Now it's checked for all rules which have scope_types set.
It's required for e.g. Neutron as it is creating Check objects based
on the defined policy rules to e.g. include in the check attributes
like network's provider parameters, etc.
Depends-On: https://review.opendev.org/c/openstack/neutron/+/815838
Depends-On: https://review.opendev.org/c/openstack/neutron/+/818725
Closes-Bug: #1923503
Change-Id: I55258c1f999c84220518d1fbbf5e1e514361cebe
Policy directory files can only add new rules or
update existing rules in cache, but cannot return back
loaded rules in memory to their default value.
This incorrect behavior was fixed in the patch.
Member "_loaded_files" of class Enforcer should keep
list of loaded policy config files paths.
In fact if the same file is changed many times
then the same file path is added many times.
If a file is deleted it's path not deleted from "_loaded_files".
The member is very misleading and is not used in code.
So this member was deleted in the patch because of
above mentioned resons.
Change-Id: I9ede38d8cf2ae968d3d8c0b1240bd6a51e6aa931
Closes-Bug: 1943584
Add file to the reno documentation build to show release notes for
stable/xena.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/xena.
Sem-Ver: feature
Change-Id: I90013a56029ff70d0112b56efd32c1d0a5a6f0e0
An earlier patch[1] added a mapping for context 'system_scope'
to 'system' when enforce was called with a RequestContext
object. However, enforce can also be called with a creds dictionary
that may contain the context 'system_scope' element. When this
occured, 'system_scope' was not mapped to 'system' and the enforce
would fail with an InvalidScope exception.
This patch moves the 'system_scope' mapping from only occuring
with RequestContext objects to also map it when a creds dictonary
is passed to enforce.
[1] https://review.opendev.org/c/openstack/oslo.policy/+/578995
Change-Id: I83a22c3f825bad0c88018118f8630a20a445965e
Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: Ic4f96634aa7fe3080c46ef411b7d47778676af1b
When service register their policy rule oslo policy does not
copy the rule and instead work on the original object.
- bd9d47aa36/oslo_policy/policy.py (L1104)
policy enforcer modify the default rules in
_handle_deprecated_rule().
- bd9d47aa36/oslo_policy/policy.py (L767-L774)
In any case, oslo policy should make copy of the registered
rules.
Another thing it fix is setting of flag
RuleDefault._deprecated_rule_handled.
Flag _deprecated_rule_handled is set to True when
_handle_deprecated_rule() is called irrespective of it
actually handle the deprecated rule and add it in OR checks.
We should set this flag when acutally deprecated rule is
handled so that if any condition change like config flag or
file rules we correctly handle deprecated rules.
Closes-Bug: #1914095
Closes-Bug: #1914592
Story: 2008556
Task: 41687
Change-Id: I154213dabd4d9eef760f0a4c9a852d504638ca8d
The policy engine converts simple strings into instances of rule
objects based on a policy DSL. This engine iterates checks and reduces
them after each iteration if performing the conversion on list of check
strings.
When we deprecate policies we apply a logical OR to make upgrades easier
for operators. The logical OR, implemented with an OrCheck, only needs
to be done once per deprecated rule. Today, we're re-initializing an
OrCheck instance each time we load rules, which happens every time
oslo_policy.policy.Enforcer.enforce() is called.
For most OpenStack usage, this isn't noticiable, especially if you're
only using it to enforce access to a specific endpoint. However, this
can get expensive if you're using the enforcer to protect the API,
protect each resource in a response, and protect each attrbute of the
resource (e.g., Neutron makes extensive usage of this pattern to
implement RBAC for resources it's responsible for).
This commit updates the RuleDefault object to track state of handling
deprecated logic ORs so that we only cast the check strings to OrCheck
instances once per rule no matter how many times we call load_rules().
Closes-Bug: 1913718
Change-Id: I539672fc220b8d7e3c47ab3dfa6670b88e3f4093
Currently, the way you replace a rule with another rule is by using the
'deprecated_rule' parameter of '(Documented)RuleDefault'. For example:
deprecated_rule = policy.DeprecatedRule(
name='foo:bar',
check_str='role:bazz'
)
policy.RuleDefault(
name='foo:create_bar',
check_str='role:bang',
description='Create a bar.',
deprecated_rule=deprecated_rule,
deprecated_reason='foo:bar has been replaced by foo:create_bar',
deprecated_since='N',
)
In this instance, we're stating that the 'foo:create_bar' policy
replaces the 'foo:bar' policy and we've used (and indeed have to use, to
avoid a 'ValueError') the 'deprecated_reason' and 'deprecated_since'
parameters on the **new** rule to illustrate why. This is confusing. The
new rule clearly isn't the one that's deprecated, so why are we stating
the 'deprecated_reason' and 'deprecated_since' there? We can clarify
this by instead specifying the reason and timeline on the deprecated
rule, like so:
deprecated_rule = policy.DeprecatedRule(
name='foo:bar',
check_str='role:bazz'
deprecated_reason='foo:bar has been replaced by foo:create_bar',
deprecated_since='N',
)
policy.RuleDefault(
name='foo:create_bar',
check_str='role:bang',
description='Create a bar.',
deprecated_rule=deprecated_rule,
)
Add support for this, with appropriate warnings to nudge people over to
the new, improved way of doing things eventually.
Change-Id: Ie4809c7749242bd092a2677b7545ef281735d984
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Add file to the reno documentation build to show release notes for
stable/victoria.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/victoria.
Change-Id: Ic9fe5dc1119eee908d0381b89f2c50e86ba4a535
Sem-Ver: feature
JSON support for policy_file has been problematic
since projects started policy-in-code. For example,
generating a sample policy file in JSON results in
all the policy-in-code rules being overridden because
it is not possible to comment out the default rules in JSON.
Asd part of migration of JSON format to YAML, this commit
deprecates the:
1. Deprecate JSON support in oslo.policy.
2. Deprecate JSON output in policy CLI tools including '--format'
option.
Partial implement blueprint policy-json-to-yaml
Change-Id: I5432a8cf80903620f48936cbbfb92ea6b6ff30fa
Add ``oslopolicy-convert-json-to-yaml`` tool which can be
used to convert the json formatted policy file to yaml format.
It takes json formatted policy file as input and convert it to
a yaml formatted policy file similar to 'oslopolicy-sample-generator'
tool except keeping the overridden rule as uncommented.
This tool does the following:
* Comment out any rules that match the default from policy-in-code.
* Keep rules uncommented if rule is overridden.
* Does not auto add the deprecated rules in the file unless it not already
present in the file.
* Keep any extra rules or already exist deprecated rules uncommented
but at the end of the file with a warning text.
I did not add the new functionality in existing 'oslopolicy-policy-upgrade'
tool because the above listed features of new tool end up creating a
complete different code path instead of reusing it from existing tool so it
better to have separate tool which can be removed in future once all deployments
are migrated to YAML formatted file.
This commits add doc and reno also for this tool
Partial implement blueprint policy-json-to-yaml
Change-Id: Icc245951b2992cc09a891516ffd14f3d4c009920
As requested in the referenced RFE bug, this is a validator tool
similar to the oslo.config validator tool that operators can use to
look for basic errors in their policy files.
It's very similar to the redundant rule tool, but I decided not to
combine them because I feel like the target use cases are enough
different to warrant separate tools. Specifically, the redundant
rule tool is looking for perfectly valid rules that just happen to
be unnecessary. The validator is looking for errors in the policy
file. While it's unlikely someone looking for redundant rules wouldn't
also want to know if there is something broken in their policy file,
it's likely that someone just looking to sanity check their policy
before deployment wouldn't want to see a bunch of messages about
redundant rules that won't cause any problems.
Change-Id: I799a754aceac080c11baffd7ff635b2a9cb825f7
Closes-Bug: 1853038
It was determined that rules from policy files located in the directory
specified in the policy_dirs option (/etc/<config_dir>/policy.d by
default) are not re-applied after the rules from the primary policy file
is re-applied due to a change.
This change introduces additional behavior to make sure the rules from
policy_dirs are reapplied if there is a change to the primary policy
file.
Change-Id: I8a6f8e971d881365c41ea409966723319d5b239a
Closes-Bug: #1880959
Related-Bug: #1880847
Switch to openstackdocstheme 2.2.0 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering
Update Sphinx version as well.
Remove docs requirements from lower-constraints, they are not needed
during install or test but only for docs building.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
Depends-On: https://review.opendev.org/728938
Change-Id: I565a343d875cea144928da007a93f0b93a5d4274
Add file to the reno documentation build to show release notes for
stable/ussuri.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/ussuri.
Change-Id: Id0e367af0c1721a83bec0df102c8e48cf52e1d86
Sem-Ver: feature
When policy change their default check_str and not override by
operator then old defaults check_str are added with OrCheck to the
new default check_str so that old defaults keep working.
If operators want to enforce the new defaults with no old defaults then
they have to overwrite the policy rule in poicy file with new default
value. This is not expected and very painful for them especially when
all policies are switching to new defaults. For example:
- https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged)
This commit adds a new config options to control the new defaults enforcement.
If True then old defaults will not be supported and also no warning will
be logged.
New config option is default to False so no change in behaviour for old users.
Change-Id: I3c2c889af25b723f1eedbe6167d614c6a4bc6cd2
Some options are now automatically configured by the version 1.20:
- project
- html_last_updated_fmt
- latex_engine
- latex_elements
- version
- release.
Change-Id: I2c9f7b72a52edde7b18dc66bcc8c655630b3bbc2
Add file to the reno documentation build to show release notes for
stable/train.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/train.
Change-Id: I8cb1d87c0a6ab7da1918e69cd52fd40276717d5b
Sem-Ver: feature
When running the tool against a project with a lot of deprecated
policies, the deprecation warnings overwhelm the important output
from the tool. Since checking for deprecations isn't the purpose of
this tool, let's just suppress warnings and limit the output to the
list of redundant policy rules that the user cares about.
I will note that the suppress_deprecation_warnings member is marked
as test only, but that was targeted at consumers of oslo.policy
rather than oslo.policy itself. I could also argue that we're
"testing" for redundant policies here, but that feels like semantic
hair splitting. :-)
Change-Id: I194af14ebd341366dbb1dd033654739a7f3d085c
Partial-Bug: 1836568
Add file to the reno documentation build to show release notes for
stable/stein.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/stein.
Change-Id: I4ab63935e8382bd0e5903297f2a5cd424884b38b
Sem-Ver: feature
Add a new "oslopolicy-policy-upgrade" commnd. Using this command,
operator can upgrade their self-defined policy files to follow
the new format in the new release when upgrading OpenStack services.
Change-Id: Iad9740bd8a5e4fdf1d1e64d61bc93f2483c531f3
This allows us to test the policy for other services which might have
different or unusual target data formats (such as Barbican). It would be
possible to pass it as a nested dictionary, e.g.:
{
"target": {
"secret": {
"project_id": "my project id"
}
}
}
or as a key pair (as oslo.policy would expect):
{
"target.secret.project_id": "my project id"
}
Both will work (note that this logic was taken from barbican).
This fixes around the limitation that the target is hardcoded to be
"project_id", and thus allows to test more scenarios (such as the
project ID not matching).
Change-Id: Ia9f7462072a8cb142251c8bb5ef19d9a25a98119
Zuul
OpenStack Release Bot