Switch to stestr
According to Openstack summit session [1], stestr is maintained project to which all Openstack projects should migrate. Let's switch to stestr as other projects have already moved to it. This change also fixes a bunch of D001 violations where lines are too long in .rst documents. [1] https://etherpad.openstack.org/p/YVR-python-pti Change-Id: Ic20ae60d9020896690c5e7f07124d7500ffd3d2d
This commit is contained in:
parent
b05d80a97a
commit
4fe55f0e82
|
@ -7,4 +7,4 @@ build
|
|||
*.swp
|
||||
*.swo
|
||||
*.pyc
|
||||
.testrepository
|
||||
.stestr/
|
||||
|
|
|
@ -0,0 +1,4 @@
|
|||
[DEFAULT]
|
||||
test_path=./tests
|
||||
top_dir=./
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
[DEFAULT]
|
||||
test_command=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ . $LISTOPT $IDOPTION
|
||||
test_id_option=--load-list $IDFILE
|
||||
test_list_option=--list
|
|
@ -5,6 +5,6 @@ pbr>=2.0.0
|
|||
sphinx!=1.6.1,>=1.5.1
|
||||
sphinxcontrib-blockdiag
|
||||
openstackdocstheme>=1.17.0 # Apache-2.0
|
||||
testrepository>=0.0.18
|
||||
stestr>=2.0.0 # Apache-2.0
|
||||
testtools>=0.9.34
|
||||
doc8
|
||||
|
|
|
@ -71,15 +71,16 @@ use to adopt the proposed default roles in a future `community goal
|
|||
Default Roles
|
||||
-------------
|
||||
|
||||
**reader**: It should only be used for read-only APIs and operations. Alternatively
|
||||
referred to as ``readonly`` or ``observer``, this role fills an extremely popular need from operators.
|
||||
**reader**: It should only be used for read-only APIs and operations.
|
||||
Alternatively referred to as ``readonly`` or ``observer``, this role fills
|
||||
an extremely popular need from operators.
|
||||
|
||||
**member**: serves as the
|
||||
general purpose ‘do-er’ role. It introduces granularity between the administrator(s)
|
||||
and everyone else.
|
||||
general purpose ‘do-er’ role. It introduces granularity between
|
||||
the administrator(s) and everyone else.
|
||||
|
||||
**admin**: This role will be only be considered appropriate for operations deemed too
|
||||
sensitive for anyone with a member role.
|
||||
**admin**: This role will be only be considered appropriate for operations
|
||||
deemed too sensitive for anyone with a member role.
|
||||
|
||||
The desired outcome of implementing the roles above is that projects should
|
||||
start moving away from the practice of hardcoding operations to specific role
|
||||
|
@ -92,10 +93,10 @@ Scope Type (Refresher)
|
|||
**project-scope**: Project-scope relates to authorization for operating in a
|
||||
specific tenancy of the cloud.
|
||||
|
||||
**system-scope**: System-scope relates to authorization for operating with APIs that
|
||||
do not map nicely to the concept of Project scope. It is **not** meant to cover *all*
|
||||
APIs across a deployment. More information about system-scope can be found in the `specification
|
||||
<http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html>`_,
|
||||
**system-scope**: System-scope relates to authorization for operating with APIs
|
||||
that do not map nicely to the concept of Project scope. It is **not** meant to
|
||||
cover *all* APIs across a deployment. More information about system-scope can
|
||||
be found in the `specification <http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html>`_,
|
||||
along with relevant historical context justifying the `need for system-scope
|
||||
<https://bugs.launchpad.net/keystone/+bug/968696>`_.
|
||||
|
||||
|
@ -103,62 +104,97 @@ Examples
|
|||
--------
|
||||
|
||||
`reader:`
|
||||
An example project-scoped application of this role would be listing project tags (``identity:get_project_tags``).
|
||||
An example system-scoped application of this role would be listing service endpoints
|
||||
(``identity:list_endpoints``).
|
||||
An example project-scoped application of this role would be listing project
|
||||
tags (``identity:get_project_tags``).
|
||||
An example system-scoped application of this role would be listing service
|
||||
endpoints (``identity:list_endpoints``).
|
||||
|
||||
`member:`
|
||||
An example project-scoped application of this role would be creating a project tag (``identity:update_project_tags``).
|
||||
An example project-scoped application of this role would be creating a project
|
||||
tag (``identity:update_project_tags``).
|
||||
An example system-scope application of this role would be updating an endpoint
|
||||
(``identity:update_endpoint``).
|
||||
|
||||
`admin:`
|
||||
An example project-scoped administrator operation would be deleting project tags (``identity:delete_project_tags``).
|
||||
An example system-scoped administrator operation would be creating an endpoint for a service
|
||||
(``identity:create_endpoint``) or listing migrations (``os_compute_api:os-migrations``).
|
||||
An example project-scoped administrator operation would be deleting project
|
||||
tags (``identity:delete_project_tags``).
|
||||
An example system-scoped administrator operation would be creating an endpoint
|
||||
for a service (``identity:create_endpoint``) or
|
||||
listing migrations (``os_compute_api:os-migrations``).
|
||||
|
||||
|
||||
The following table is neither a final nor a comprehensive list of all possible rules/policies.
|
||||
It serves merely as a snippet of existing rules to showcase how policies, scope, and the new
|
||||
default roles can work together to provide a richer policy experience.
|
||||
The following is neither a final nor a comprehensive list of all possible
|
||||
rules/policies. It serves merely as a snippet of existing rules to showcase how
|
||||
policies, scope, and the new default roles can work together to provide a
|
||||
richer policy experience.
|
||||
|
||||
+-------------+------------------------------+---------------------------------+---------------------------------+
|
||||
| | reader | member | admin |
|
||||
+=============+==============================+=================================+=================================+
|
||||
| **Project** | * identity:list_project_tags | * identity:list_project_tags | * identity:list_project_tags |
|
||||
| | * identity:get_project_tag | * identity:get_project_tag | * identity:get_project_tag |
|
||||
| | | * identity:update_project_tags | * identity:update_project_tags |
|
||||
| | | | * identity:create_project_tag |
|
||||
| | | | * identity:delete_project_tags |
|
||||
+-------------+------------------------------+---------------------------------+---------------------------------+
|
||||
| **System** | * identity:list_endpoints | * identity:list_endpoints | * identity:list_endpoints |
|
||||
| | * identity:get_endpoint | * identity:get_endpoint | * identity:get_endpoint |
|
||||
| | | * identity:update_endpoint | * identity:update_endpoint |
|
||||
| | | | * identity:create_endpoint |
|
||||
| | | | * os_compute_api:os-hypervisors |
|
||||
| | | | * os_compute_api:os-migrations |
|
||||
+-------------+------------------------------+---------------------------------+---------------------------------+
|
||||
Project Reader
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_project_tags``
|
||||
* ``identity:get_project_tag``
|
||||
|
||||
Project Member
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_project_tags``
|
||||
* ``identity:get_project_tag``
|
||||
* ``identity:update_project_tags``
|
||||
|
||||
Project Admin
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_project_tags``
|
||||
* ``identity:get_project_tag``
|
||||
* ``identity:update_project_tags``
|
||||
* ``identity:create_project_tags``
|
||||
* ``identity:delete_project_tags``
|
||||
|
||||
System Reader
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_endpoints``
|
||||
* ``identity:get_endpoint``
|
||||
|
||||
System Member
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_endpoints``
|
||||
* ``identity:get_endpoint``
|
||||
* ``identity:update_endpoints``
|
||||
|
||||
System Admin
|
||||
~~~~~~~~~~~~
|
||||
|
||||
* ``identity:list_endpoints``
|
||||
* ``identity:get_endpoint``
|
||||
* ``identity:update_endpoints``
|
||||
* ``identity:create_endpoints``
|
||||
* ``os-compute-api:os-hypervisors``
|
||||
* ``os-compute-api:os-migrations``
|
||||
|
||||
Example snippets of various policy files, or rendered snippets, could look like
|
||||
the following.
|
||||
|
||||
.. note::
|
||||
|
||||
The default roles discussed will be created by Keystone, during the bootstrap process, using `implied roles
|
||||
The default roles discussed will be created by Keystone, during the bootstrap
|
||||
process, using `implied roles
|
||||
<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_.
|
||||
As indicated in the above table, having ``admin`` role implies a user also has the same rights as
|
||||
the ``member`` role. Therefore this user will also has the same rights as the ``reader`` role as
|
||||
``member`` implies ``reader``.
|
||||
As indicated in the above table, having ``admin`` role implies a user also
|
||||
has the same rights as the ``member`` role. Therefore this user will also has
|
||||
the same rights as the ``reader`` role as ``member`` implies ``reader``.
|
||||
|
||||
This keeps policy files clean. For example:
|
||||
This keeps policy files clean. For example, the following are equivalent as a
|
||||
result of implied roles:
|
||||
|
||||
"identity:list_endpoints": "role:reader OR role:member OR role:admin" is equivalent to
|
||||
"identity:list_endpoints": "role:reader" as a result of the implied roles chain.
|
||||
"identity:list_endpoints": "role:reader OR role:member OR role:admin"
|
||||
"identity:list_endpoints": "role:reader"
|
||||
|
||||
The chain of implied roles will be documented alongside of the `policy-in-code defaults
|
||||
<https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py>`_ in addition to
|
||||
general Keystone documentation updates noting as much.
|
||||
The chain of implied roles will be documented alongside of the
|
||||
`policy-in-code defaults
|
||||
<https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py>`_
|
||||
in addition to general Keystone documentation updates noting as much.
|
||||
|
||||
::
|
||||
|
||||
|
@ -189,53 +225,60 @@ Let's assume the following role assignment exist:
|
|||
|
||||
Given the above assignments and policies, the following would be possible:
|
||||
|
||||
**Alice** can list or retrieve specific endpoints. Alice cannot do any project specific
|
||||
operations since her authorization is limited to the deployment system.
|
||||
**Alice** can list or retrieve specific endpoints. Alice cannot do any project
|
||||
specific operations since her authorization is limited to the deployment
|
||||
system.
|
||||
|
||||
**Bob** can retrieve specific endpoints, list them, and update them. He cannot create new
|
||||
endpoints, or delete existing ones. Bob cannot do any project specific operations because his
|
||||
**Bob** can retrieve specific endpoints, list them, and update them. He cannot
|
||||
create new endpoints, or delete existing ones. Bob cannot do any project
|
||||
specific operations because his authorization is limited to the deployment
|
||||
system.
|
||||
|
||||
**Charlie** can retrieve specific endpoints, list, as well as create them.
|
||||
Additionally, Charlie can list information on migrations as well as
|
||||
hypervisors. He cannot perform any project specific operations because his
|
||||
authorization is limited to the deployment system.
|
||||
|
||||
**Charlie** can retrieve specific endpoints, list, as well as create them. Additionally, Charlie
|
||||
can list information on migrations as well as hypervisors. He cannot perform any project specific
|
||||
operations because his authorization is limited to the deployment system.
|
||||
**Qiana** can list all tags and get details about a specific tag within Project
|
||||
Alpha. She may not perform system specific policies because her authorization
|
||||
is on a single project.
|
||||
|
||||
**Qiana** can list all tags and get details about a specific tag within Project Alpha. She may not
|
||||
perform system specific policies because her authorization is on a single project.
|
||||
**Rebecca** can list all tags, get details about a specific tag, and update a
|
||||
tag within Project Alpha. She cannot perform any system specific policies
|
||||
because her authorization is on a single project.
|
||||
|
||||
**Rebecca** can list all tags, get details about a specific tag, and update a tag within Project
|
||||
Alpha. She cannot perform any system specific policies because her authorization is on a single
|
||||
project.
|
||||
|
||||
**Steve** can list all tags, create new tags, get details about a specific tag, update a tag, and
|
||||
delete tags within Project Alpha. He cannot perform any system specific policies because his
|
||||
authorization is on a single project.
|
||||
**Steve** can list all tags, create new tags, get details about a specific tag,
|
||||
update a tag, and delete tags within Project Alpha. He cannot perform any
|
||||
system specific policies because his authorization is on a single project.
|
||||
|
||||
Risk Mitigation
|
||||
---------------
|
||||
|
||||
**Scenario One -- A role serving the purposes described in this spec exists under another name**:
|
||||
Let us assume that Deployment A already has ``Role X`` which serves the purpose of the proposed here as
|
||||
the ``reader`` role. In this instance, it is reasonable to assume that operators may have custom policy
|
||||
work in place and do not want to port immediately.
|
||||
**Scenario One -- A role serving the purposes described in this spec exists
|
||||
under another name**: Let us assume that Deployment A already has ``Role X``
|
||||
which serves the purpose of the proposed here as the ``reader`` role. In this
|
||||
instance, it is reasonable to assume that operators may have custom policy work
|
||||
in place and do not want to port immediately.
|
||||
|
||||
This issue may be mitigated through the use of implied roles. Operators need simply to ensure that
|
||||
``reader`` implies ``Role X``. Please review the documentation on `implied roles
|
||||
<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_. for
|
||||
specific instructions on how make one role imply another.
|
||||
This issue may be mitigated through the use of implied roles. Operators need
|
||||
simply to ensure that ``reader`` implies ``Role X``. Please review the
|
||||
documentation on `implied roles
|
||||
<https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_.
|
||||
for specific instructions on how make one role imply another.
|
||||
|
||||
**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already exists**: Let us assume
|
||||
that Deployment B already has a ``member`` role. Keystone will not attempt to overwrite any existing roles
|
||||
that have been populated. It will instead note that a role with the name ``member`` already exists in log
|
||||
output.
|
||||
**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already
|
||||
exists**: Let us assume that Deployment B already has a ``member`` role.
|
||||
Keystone will not attempt to overwrite any existing roles that have been
|
||||
populated. It will instead note that a role with the name ``member`` already
|
||||
exists in log output.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
reader/writer/admin vs reader/member/admin. There was much debate regarding the naming
|
||||
conventions for these roles. We have opted to use `reader`, `member`, and `admin` as we
|
||||
believe they most accurately describe their purpose when the context of OpenStack is taken
|
||||
into consideration.
|
||||
reader/writer/admin vs reader/member/admin. There was much debate regarding the
|
||||
naming conventions for these roles. We have opted to use `reader`, `member`,
|
||||
and `admin` as we believe they most accurately describe their purpose when the
|
||||
context of OpenStack is taken into consideration.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
@ -258,8 +301,8 @@ Work Items
|
|||
* Implement scope_types for all policies in Keystone
|
||||
* Remove @protected decorator
|
||||
* Document how operators may generate policy files with service specific roles
|
||||
* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack Community Goal
|
||||
to promote default roles across the other services.
|
||||
* Prepare Proof-of-Concept to demo and facilitate acceptance of an OpenStack
|
||||
Community Goal to promote default roles across the other services.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
@ -297,6 +340,6 @@ Resources
|
|||
|
||||
.. note::
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License. http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
|
|
Loading…
Reference in New Issue