| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I2837959e8b03f98e8d947787d5c81569fe69acf6
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I138e5cf6deb82ad29a2bf70392c1859354b84800
|
|/
|
|
|
|
|
|
| |
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: https://github.com/openstack/oslo.policy/blob/de857746867344c1a3f9f1dadf87b7ae046a1fc1/oslo_policy/_checks.py#L299
|
|
|
|
|
| |
Change-Id: Ifcfc88a67b038528f03756d550e1ddf8726cb37a
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
New theme of docs respects pygments_style.
more info: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I9c03ccdf5dd63f2f13b34f72ebbe8c77168287b6
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I066ea68633e0bd906fc5b45aaa823e6e07fbae3a
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
| |
Change-Id: I6c98efa7463fc71176f9635f6ffebb5c7050bd49
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OpenStack is dropping the py2.7 support in Ussuri cycle.
Complete discussion & schedule can be found in
-
http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.html
- https://etherpad.openstack.org/p/drop-python2-support
Ussuri Communtiy-wide goal:
https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html
Change-Id: If6a07eee86a2aaf65bdf9fbb338809ad47e02a46
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For compliance with the Project Testing Interface as described in:
https://governance.openstack.org/tc/reference/project-testing-interface.html
For more detials information, please refer to:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125710.html
Change-Id: I1c10b87297a23e010613e951f65913bb54baf6b9
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I2f12fb5058984c1fc6beda4d13f934dd9b218218
|
|
|
|
|
| |
Change-Id: I06b5f84891c7d90837cfbbdbb532f8479620c6c7
Closes-Bug: #1827761
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This commit addresses nits from
https://review.openstack.org/#/c/604192/1
Change-Id: I2ca0cd67eca4d1b2d0320f7ecb40c9ff55229b12
|
|\ |
|
| |
| |
| |
| | |
Change-Id: Ie752d7e9d40be33ba29f6c14d6a6f16e1fcc66f1
|
|/
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|/ /
| |
| |
| |
| |
| |
| | |
No reason for this to be executable.
Change-Id: I125a5b73101fa6f1d55f4ded91d3b4192c91d87e
Signed-off-by: Stephen Finucane <sfinucan@redhat.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
|
|/
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| | |
Change-Id: I3a35af82ff83946e30f00171bd50c2eac7b9d0a5
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
|
|/
|
|
|
| |
Change-Id: I0d801ee399331dfcd5d0bdcae678d14ef44e5b2f
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
|
|
|
|
|
| |
Change-Id: Iaefc26222d42663423f736946dea97c5613b7d1c
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
|
|
|
|
|
|
|
|
|
|
|
| |
We recently merged a patch that enhanced the RuleDefault object by
allowing it to have more attributes:
Ie9b335420394166bb39c43e3d26fcc9237ffd1a0
This commit describes its usage in the usage documentation.
Change-Id: I8f6e6bc289a046b09529f707874314c69757ee11
|