This fixes the following error in the doc job.
```
TypeError: not all arguments converted during string formatting
```
Change-Id: If67f629dfd6b07ed198155bec43a128369b7affa
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
This patch changes 'oslopolicy-policy-generator' to
'oslopolicy-checker' in oslopolicy-checker.rst.
Change-Id: I73621ced00404d164fdb23f077ee36fbb6faf717
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
As `--format` option was dropped in oslopolicy-policy-generator, remove
examples of the option in documentation.
Change-Id: I20f748dadecc15eaad6326a20a121cab4c1a995e
Signed-off-by: Yasufumi Ogawa <yasufum.o@gmail.com>
Introduced changes:
- pre-commit config and rules
- Add pre-commit to pep8 gate, Flake8 is covered in the pre-commit hooks.
- Applying fixes for pre-commit compliance in all code.
Also commit hash will be used instead of version tags in pre-commit to
prevend arbitrary code from running in developer's machines.
pre-commit will be used to:
- trailing whitespace;
- Replaces or checks mixed line ending (mixed-line-ending);
- Forbid files which have a UTF-8 byte-order marker (check-byte-order-marker);
- Checks that non-binary executables have a proper
shebang (check-executables-have-shebangs);
- Check for files that contain merge conflict strings (check-merge-conflict);
- Check for debugger imports and py37+ breakpoint()
calls in python source (debug-statements);
- Attempts to load all yaml files to verify syntax (check-yaml);
- Run flake8 checks (flake8) (local)
For further details about tests please refer to:
https://github.com/pre-commit/pre-commit-hooks
Change-Id: Ia9f7040f9966f1492c590a005f55ef7f3b67f0c9
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
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
The definition of an "access" file is very vague, but oslopolicy-checker
expects it to be a token response body from keystone. If you don't pass
a token response explicitly, oslopolicy-checker will fail.
Change-Id: I5362fabb0344b67996367382dbc173eeaf39b06b
When doing a literal comparison in a rule, it is necessary to enclose
the literal in single quotes. This is not apparent from the existing
docs and is only mentioned in a private module[0] which does not
appear in the published docs. This change adds an example that covers
literal comparisons and briefly discusses how to determine what
fields are available for comparison. The latter should be expanded
upon at some point as it is important for anyone writing their own
policy rules.
Change-Id: I383f179ce274c1cf00f83d006a1dcddd40c52084
0: de85774686/oslo_policy/_checks.py (L299)
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
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
The oslo.policy docs on writing custom policy checks use things like
the admin role without explaining where it comes from. This change
adds a link to the Keystone docs that explain which roles are created
by default and what they provide access to.
Change-Id: I70c01ad88344edd2db384da8b24ba0238764a8ec
It was confusing that this was titled "Writing custom check rules"
when it only discussed HTTP check rules. This makes it more clear
what the document deals with.
Change-Id: If23d817ab1392b97f1e2d8cfc3ddef2be9d9619c
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
Sphinx 1.8 introduced [1] the '--keep-going' argument which, as its name
suggests, keeps the build running when it encounters non-fatal errors.
This is exceptionally useful in avoiding a continuous edit-build loop
when undertaking large doc reworks where multiple errors may be
introduced.
[1] https://github.com/sphinx-doc/sphinx/commit/e3483e9b045
Change-Id: I9af0e8323b85d47983274b4d45b27f6c036ea5a8
Previously the code snippet for tox.ini genpolicy pointed to the output yaml
instead of the config file.
Change-Id: Ia575beabad06f081d4f68bff8fcf83566331f1d6
In the "special checks" section, 'role' and 'rule' are keywords
and should not be enclosed in '< >'.
Change-Id: Ia3c1b47f1c8452bcca62961de4414d21d7ebf481
Inconsistent policy names across OpenStack services has been a pain
point for operators and users for a long time. This is an attempt at
documenting a set of conventions for developers to work towards to
provide a more uniform experience. These conventions were discussed
publicly on the mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2018-September/134597.html
Change-Id: I8831c44a3544d11c0bb1c0ce58d1a140f861e22b
The Syntax section of this is supposed to be describing the YAML
format, but references the JSON format.
This commit updates the documentation to remove this reference.
Change-Id: I7bfc11a3f1ecc57e3865d308b7a9bffd8453bce2
This commit adds usage and examples for generating sample policy
files and listing redundant policy rules.
Change-Id: I2ff00a0a038fde5596ec2fe35de1b7647efcbb9c
Closes-Bug: 1741073
This commit simply expands on the CLI usage document so that we can
easily expand it to include new sections.
Change-Id: Ib1c4d6999e2cdcb078609f0cf612f7073d2747c4
When we initially implemented the scope_types attribute, we included
some documentation but we never explicitly described how to use
scope_types, what was officially supported, or why the attribute is
important.
This commit attempts to add documentation that clarifies those areas.
Change-Id: I46d351b3c9888a703d520082f10ebbedc53973ff
Closes-Bug: 1771621
Some projects have multiple policy files for different parts of their
API. Make the sample generator extension support this by letting the
policy_generator_config_file option be set to a list of tuples mapping
the config file to the output file base name, as we do in the sample
generator in oslo.config.
Change-Id: I0c7fa409a1ed0f49d65c9b90b71317066f6d3505
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The oslo.policy bits to generate documentation and use the oslo.policy
CLI scripts is usually copy/pasted from other services that have
already done that work. This commit attempts to pull that information
into the usage section of oslo.policy, complete with examples, instead
of making OpenStack developers hunt through projects to find examples
they can use. Or wonder why or how this tooling works.
Change-Id: Ie74888b09bb836c192a88c5beddd86297c8bceda
Closes-Bug: 1766953
This change will help oslo.policy consume different levels of scope
and enforce proper admin-ness across OpenStack. The idea is that once
keystone has the ability to issue system-scoped tokens, we can start
enforcing partial scope checks in `Enforcer.enforce()`.
bp add-scope-to-policy
Change-Id: I7fa171d859d82939511f8279e4e9464f792ed2cd
In Icde2b26a38d7c7842defae053228d9208454b969, we added support for
stevedore based external/custom plugins. In this changeset, we
add a release note and documentation on how things work.
Change-Id: Ie0b773dc1147f5ef898d17e8f84c946c39fdf5cd
Takashi Kajinami