| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
This patch changes 'oslopolicy-policy-generator' to
'oslopolicy-checker' in oslopolicy-checker.rst.
Change-Id: I73621ced00404d164fdb23f077ee36fbb6faf717
|
| |
|
|
|
|
|
|
| |
The patch bumps min version of tox to 3.18.0 in order to
replace tox's whitelist_externals by allowlist_externals option:
https://github.com/tox-dev/tox/blob/master/docs/changelog.rst#v3180-2020-07-23
Change-Id: I28abab34878d3c62a88be8894107f994d02c1c4f
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
inspect.getargspec() is deprecated since py3
[1] https://docs.python.org/3/library/inspect.html#inspect.getargspec
Change-Id: If7492d7f755c80687f867428d80e4efb1e1a5d57
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I58b9521882d81ab508bb7ce28308d88771daf1fe
|
| |
|
|
| |
Change-Id: I8162d5c413de6a73614443fdcd30ee472cb81035
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We facing errors related to the new pip resolver, this
topic was discussed on the ML and QA team proposed to
to test lower-constraints [1].
I propose to drop this test because the complexity and recurring pain needed
to maintain that now exceeds the benefits provided by this mechanismes.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html
Change-Id: Ifcaf6993517d02bf54cd144efd247832947a009f
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
We have many if else condition to pick the
right policy filebut there is no debugging log
to have useful info to know if expected policy file
is not picked.
Change-Id: I507c58a6dca06d0cc6f306bcd063c700c18cc5f7
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Moving on py3 as the default runtime for tox to avoid to update this at
each new cycle.
Wallaby support officially the following runtimes [1]:
- Python 3.6
- Python 3.8
During Victoria Python 3.7 was used as the default runtime [2] however this
version isn't longer officially supported.
[1] https://governance.openstack.org/tc/reference/runtimes/wallaby.html#python-runtimes-for-wallaby
[2] https://governance.openstack.org/tc/reference/runtimes/victoria.html#python-runtimes-for-victoria
Change-Id: I4a244fc6f2d0d614d579fb944255be728fee1d61
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is an automatically generated patch to ensure unit testing
is in place for all the of the tested runtimes for xena.
See also the PTI in governance [1].
[1]: https://governance.openstack.org/tc/reference/project-testing-interface.html
Change-Id: Ifb43d051c91501f870233f107e4d9e14c7473b6b
|
| |\ \ \ \
| |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
New tests are:
- Permission denied
- File not found
Change-Id: I6d3343319ca6519fd9d215f2e8d3fa38516e9f4d
|
| |\ \ \ \ \
| |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
For now, policy file unaccessible due to access permission leads to
silent failure without any notifictaion. Side effects of it are also
affected by policy caching and might be quite confusing, like periodic
disappearing of Horizon panels. Proposed patch added handling of such
errors.
Closes-bug: #1836390
Change-Id: I0d67b6e7c2dcaa63d6bb807f013e5e7334efc715
|
| |\ \ \ \ \
| |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: Ife6600da240f830aa0080e3f214cedf1389ea512
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Sometimes it's not easy to identify the target resource based on the API call.
Adding some more details on how API attribute is used as a targer, with an
example on how to compare the API calls logs with the target resource would
help to debug policy issues.
Change-Id: I1318cceb5c0a32c258e6799a872a5dea6482c6de
Closes-Bug: #1886857
|
| |\ \ \ \ \ \
| |_|_|/ / /
|/| | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This was lost in a previous change, but in the interest of not holding
up the merge of the functional part of it I'm fixing the test in this
followup. The new version of the test verifies that the rule isn't
overwritten by a second call to load_rules, which is what would
happen if we called the deprecation handler again.
Change-Id: Idc9dd353463da63a2108782f7b141d1d8014d180
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The goal here is to avoid conflicts between flake8 and hacking version each
2 days.
Inspired from nova's approach[1].
The flake8 version to install will be determined by hacking and
requirements[2] will stay aligned instead of relying on different versions.
[1] https://opendev.org/openstack/nova/src/branch/master/.pre-commit-config.yaml#L26-L35
[2] https://opendev.org/openstack/hacking/src/branch/master/requirements.txt#L1
Change-Id: Id33601ce5949950e4791052ea34a4bf4b0e02158
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There's no functional changes here other than moving the initializer
documentation for the 'DeprecatedRule' from the '__init__' docstring to
the class' docstring. This allows us to remove '__init__' entirely since
it was just calling the superclass.
Change-Id: I7437cf00b2ba5c02926dc8c2435e237ef730f2b1
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We obviously can't do much about people accessing the private functions,
but this should avoid some obvious bugs. If people want to change the
rules, they should either state a different definition in a file or
change the definition in code.
Change-Id: Ibcbf5292977e5264bf7eedd225cbab83e683e394
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There are two big issues with this. Firstly, as noted in bug #1914095,
we're not copying the provided 'Rule' object which means if we create an
enforcer and the rule is modified, then a second enforcer in the same
process will ultimately end up using the same modified 'Rule' object
will be used. Secondly, while the 'check' attribute is modified the
'check_str' attribute is not. This is immensely confusing for people
debugging.
Resolve both issues by not modifying this check at all and instead build
the combined check and store this.
Change-Id: Iff85a9134f4db7c0355da2858deb8a704d044634
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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>
|
| |\ \ \ \ \ \
| |/ / / / / |
|
| | | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Many of requests' APIs accept a 'verify' parameter which can be a
boolean value or a path to either a CA cert bundle or a directory of CA
certs. If 'verify=True' is set, requests will look for two environment
variables, 'REQUESTS_CA_BUNDLE' and 'CURL_CA_BUNDLE', that, if set,
should specify a path to CA certs. If either of these are found,
'requests' overrides the 'True' value with the value of the environment
variable [1]. From the docs [2]:
This list of trusted CAs can also be specified through the
REQUESTS_CA_BUNDLE environment variable. If REQUESTS_CA_BUNDLE is not
set, CURL_CA_BUNDLE will be used as fallback.
This can cause test failures on environments where either of these are
set. Ensure this doesn't happen by using the 'EnvironmentVariable'
fixture to unset these environment variables.
[1] https://github.com/psf/requests/blob/v2.25.0/requests/sessions.py#L717-L719
[2] https://requests.readthedocs.io/en/master/user/advanced/#ssl-cert-verification
Change-Id: I808c9102b214aa25144e88e7773a9890ab0a5bdc
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
| |\ \ \ \ \
| |_|/ / /
|/| | | | |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We do not test the olso policy master code changes with
services unit or functional tests. Tempest job initialize
policy once and run with default rules so it will not be able
to catch all the scenario what unit or functional job does.
They initialize or override policy in parallel and sometime
that help to find the issue like
- https://bugs.launchpad.net/oslo.policy/+bug/1914095
Also this will help us to avoid any new breaking release which
is detected at the time when requirement u-c are updated
Example: https://review.opendev.org/c/openstack/requirements/+/773779
Currently this commit adds only nova & neutron testing but we can add
more service testing later.
Change-Id: Ic54b229a4bf1325adac2cab747bcd19b9f8ecb01
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | | |
Change-Id: I2837959e8b03f98e8d947787d5c81569fe69acf6
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When service register their policy rule oslo policy does not
copy the rule and instead work on the original object.
- https://github.com/openstack/oslo.policy/blob/bd9d47aa36ad6f2f4746f09a267d7ce809a820f4/oslo_policy/policy.py#L1104
policy enforcer modify the default rules in
_handle_deprecated_rule().
- https://github.com/openstack/oslo.policy/blob/bd9d47aa36ad6f2f4746f09a267d7ce809a820f4/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
|
| |\ \ \ \ |
|
| | | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | | |
collections.MutableMapping has been deprecated since Python 3.3 and
is removed in Python 3.10. The functionality should be identical.
Change-Id: Ic96309fef409ba01dd24a3a70ff132a9f5352f9c
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
UPPER_CONSTRAINTS_FILE is old name and deprecated
-https://zuul-ci.org/docs/zuul-jobs/python-roles.html#rolevar-tox.tox_constraints_file
This allows to use lower-constraints file as more
readable way instead of UPPER_CONSTRAINTS_FILE=<lower-constraints file>.
[1] https://review.opendev.org/#/c/722814/
Change-Id: I5d023d0c1e74b01bb3743c54f4a0536085b98e93
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
hacking 3.1.0 depended on 'flake8<3.8.0,>=3.6.0', while we were
specifying flake 3.8.3. This resulted in an error when using the
dependency resolver introduced in pip 20.3. Resolve this by bumping to
hacking 3.2.0.
We also remove bandit and pre-commit from test-requirements, since these
are linters which are not managed by upper-constraints and are not
necessary to run tests. oslo.context is also specified in both
requirements.txt and test-requirements.txt, so we remove it from the
latter.
Change-Id: I829870c327b73b583877b9b969ee38f0bcaa1495
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Description and operators are mandatory parameter for
DocumentedRuleDefault but few services still using the
RuleDefault for exmaple glance
- https://github.com/openstack/glance/blob/1344c45772c1a77107f621632642cf1488e431db/glance/policies/image.py#L16
To make work on oslopolicy-j2y-convertor tool to covert
the JSON file for such services we need to pass description
in preparing DocumentedRuleDefault for this tool to generate
the yaml file with rule description. For such cases, it add
rule name as description.
Also for 'operations', do not write it in generate file
for RuleDefault as that end up with blank space.
Change-Id: I910291a152402051b1eac96c3ec16c3f0bb8bbb7
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As part of community goal[1], each services are changing the default
value of 'CONF.oslo_policy.policy_file' config option from 'policy.json'
to 'policy.yaml'. oslo policy select the default value from
CONF.oslo_policy.policy_file which will be policy.yaml as service will
start changing the default. To avoid breaking the existing deployment which
are relying on old default (policy.json) file, a new fallback logic
is implemented. If new default file 'policy.yaml' does not exist but old
default 'policy.json' exist then fallback to use old default file.
Each services are going to add upgrade checks and warnings for using JSON
formatted policy file so in future we cna remove this fallback logic.
This logic was done in nova in Victoria cycle when nova changed the
default value - https://review.opendev.org/#/c/748059/ . Moving this
to oslo policy side will avoid the duplication on services side.
Also it provides a flag to disable this fallback.
[1] https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: If72b2fcc3cfd8116b575ed7b9e3870df634fd9af
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Change-Id: I138e5cf6deb82ad29a2bf70392c1859354b84800
|
| |\ \ \
| |_|/
|/| | |
|
