Update "Secure RBAC Ready" spec
The initial spec was a bit optimistic about how much would be accomplished in Xena. Additionally, this initiative has been formalized as a multi-cycle community goal and the direction of the effort has been revised and expanded. So update the Xena spec to reflect what was actually done in Xena, and add a new spec for the continuation of this work in Yoga. Change-Id: If6c289d6957bd739ed893f01519441e6039a7d00
This commit is contained in:
Brian Rosmaita
parent
06c53c4935
commit
de4308f4a7
@ -8,7 +8,7 @@
|
|||||||
Make Cinder Consistent and Secure RBAC Ready
|
Make Cinder Consistent and Secure RBAC Ready
|
||||||
============================================
|
============================================
|
||||||
|
|
||||||
https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready
|
https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-x
|
||||||
|
|
||||||
Revise Cinder's policy definitions to support the community-wide
|
Revise Cinder's policy definitions to support the community-wide
|
||||||
Consistent and Secure RBAC effort.
|
Consistent and Secure RBAC effort.
|
||||||
@ -45,9 +45,42 @@ Some examples:
|
|||||||
Proposed change
|
Proposed change
|
||||||
===============
|
===============
|
||||||
|
|
||||||
Make changes to cinder so that it can recognize the scope of a token and
|
Make changes to the cinder default policies so that the default configuration
|
||||||
add policy checkstrings to implement the "personas" described in
|
recognizes the keystone 'reader' role and treats it appropriately. This will
|
||||||
https://review.opendev.org/c/openstack/cinder/+/763306
|
entail rewriting all policies that don't govern "Admin API" calls.
|
||||||
|
|
||||||
|
For Xena, we'll implement three personas using project-scope only. What
|
||||||
|
this means is that any cinder user must have a role on a project in order
|
||||||
|
to pass policy checks. This is basically what we have now, except that
|
||||||
|
we'll distinguish the 'member' role on a project as distinct from a 'reader'
|
||||||
|
role on a project.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
What exactly "personas" are and what they can do relative to the Block
|
||||||
|
Storage API are described in the `Policy Personas and Permissions
|
||||||
|
<https://docs.openstack.org/cinder/xena/configuration/block-storage/policy-personas.html>`_
|
||||||
|
document.
|
||||||
|
|
||||||
|
Additionally, we'll address the following issues:
|
||||||
|
|
||||||
|
* New tests will need to be added, because previously we only needed to
|
||||||
|
distinguish between a "cinder administrator" and an "end user", whereas now
|
||||||
|
we'll have to make distinctions between a larger number of "personas" who can
|
||||||
|
make API calls.
|
||||||
|
|
||||||
|
* We currently have some unrestricted policies (that is, the check string is
|
||||||
|
``""``). Their checkstrings will be rewritten to something more specific and
|
||||||
|
appropriate.
|
||||||
|
|
||||||
|
* We currently have some single policies that govern create, read, update,
|
||||||
|
and delete operations on cinder resources. These will need to be split
|
||||||
|
up into finer-grained policies so that a user with only a 'reader' role
|
||||||
|
can read a resource without modifying it.
|
||||||
|
|
||||||
|
See the "Implementation Strategy" outlined in the `Policy Personas and
|
||||||
|
Permissions
|
||||||
|
<https://docs.openstack.org/cinder/xena/configuration/block-storage/policy-personas.html>`_ for more details.
|
||||||
|
|
||||||
|
|
||||||
Alternatives
|
Alternatives
|
||||||
------------
|
------------
|
||||||
@ -135,24 +168,22 @@ Work Items
|
|||||||
validate tests of the default policies.
|
validate tests of the default policies.
|
||||||
https://review.opendev.org/c/openstack/cinder/+/763306
|
https://review.opendev.org/c/openstack/cinder/+/763306
|
||||||
|
|
||||||
* Policy update patches (adding project scope):
|
* Policy update patches:
|
||||||
https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac
|
https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac
|
||||||
|
|
||||||
* Testing patches. Groundwork patch is
|
* Testing patches. Groundwork patch is
|
||||||
|
https://review.opendev.org/c/openstack/cinder/+/805316
|
||||||
|
|
||||||
|
We'll work with the current structure in cinder of individual files
|
||||||
|
in the cinder/policies directory for specific sets of policies, and
|
||||||
|
add the tests to the same patch where the policies are redefined.
|
||||||
|
|
||||||
|
* Tempest testing. Groundwork patch is
|
||||||
https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915
|
https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915
|
||||||
|
|
||||||
Initial test patches:
|
Initial test patches:
|
||||||
https://review.opendev.org/q/project:openstack/cinder-tempest-plugin+topic:secure-rbac
|
https://review.opendev.org/q/project:openstack/cinder-tempest-plugin+topic:secure-rbac
|
||||||
|
|
||||||
* Client changes to support system scope:
|
|
||||||
https://review.opendev.org/c/openstack/python-cinderclient/+/776469
|
|
||||||
|
|
||||||
* Relax the cinder REST API to handle system scope:
|
|
||||||
https://review.opendev.org/c/openstack/cinder/+/776468
|
|
||||||
|
|
||||||
(For more about this, see the `Xena PTG discussion
|
|
||||||
<https://wiki.openstack.org/wiki/CinderXenaPTGSummary#Consistent_and_Secure_RBAC>`_.)
|
|
||||||
|
|
||||||
|
|
||||||
Dependencies
|
Dependencies
|
||||||
============
|
============
|
||||||
@ -162,9 +193,18 @@ None, the required changes in Keystone and oslo.policy merged long ago.
|
|||||||
Testing
|
Testing
|
||||||
=======
|
=======
|
||||||
|
|
||||||
* Because of the complexity of the policy configuration, testing will be
|
* We'll need a flexible testing framework because we are going from 2
|
||||||
done mostly in the cinder-tempest-plugin so that each persona can be
|
personas in Wallaby to 3 personas in Xena to 5 personas in Yoga, and
|
||||||
tested against a real Keystone instance.
|
we will need to be sure that the deprecated policy checkstrings continue
|
||||||
|
to work appropriately until they are removed. Thus some kind of
|
||||||
|
ddt-based approach where we have some base tests and run all the
|
||||||
|
different kinds of users through them makes a lot of sense.
|
||||||
|
|
||||||
|
* As a stretch goal, because of the complexity of the policy configuration,
|
||||||
|
it would be good to have testing in the cinder-tempest-plugin so that each
|
||||||
|
persona can be tested against a real Keystone instance. This would also
|
||||||
|
allow using tempest for testing the consistency of the Secure and Consistent
|
||||||
|
RBAC across openstack projects.
|
||||||
|
|
||||||
Documentation Impact
|
Documentation Impact
|
||||||
====================
|
====================
|
||||||
|
|||||||
268
specs/yoga/s-rbac-ready.rst
Normal file
268
specs/yoga/s-rbac-ready.rst
Normal file
@ -0,0 +1,268 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==========================================================
|
||||||
|
The Return of Make Cinder Consistent and Secure RBAC Ready
|
||||||
|
==========================================================
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/cinder/+spec/s-rbac-ready-y
|
||||||
|
|
||||||
|
Revise Cinder's policy definitions to support the
|
||||||
|
`Consistent and Secure Default RBAC` community goal [1]_.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Cinder policies currently rely only on roles and don't recognize scope, which
|
||||||
|
was introduced into Keystone in Queens. As a result, implementing something
|
||||||
|
like an administrator who can only perform nondestructive actions in Cinder
|
||||||
|
is very complicated and error-prone.
|
||||||
|
(See, for example, `Policy configuration HowTo
|
||||||
|
<https://docs.openstack.org/cinder/latest/configuration/block-storage/policy-config-HOWTO.html>`_
|
||||||
|
in the Cinder documentation.)
|
||||||
|
|
||||||
|
Using token scope and other Keystone Queens-era improvements such as role
|
||||||
|
inheritance, it is possible to define policy rules that recognize a set of
|
||||||
|
useful "personas". If all OpenStack services define policy rules to support
|
||||||
|
this (which is the "consistent" part), operators will not have to rewrite
|
||||||
|
policies in an attempt to create such personas themselves, but can instead
|
||||||
|
use tested default policies (which is the "secure" part).
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
=========
|
||||||
|
|
||||||
|
Some examples:
|
||||||
|
|
||||||
|
* An operator wants to have an administrator who can perform only
|
||||||
|
nondestructive actions.
|
||||||
|
* An operator wants to have different levels of end user in each project
|
||||||
|
(for example, a "project manager" who can do more in the project
|
||||||
|
than just a "project member").
|
||||||
|
* An operator wants to have an system administrator who can manage the
|
||||||
|
cinder services, but cannot mess with resources owned by projects that
|
||||||
|
the administrator isn't a member of.
|
||||||
|
* An operator wants to have an customer support administrator who can can
|
||||||
|
perform admin-only actions on resources owned by various projects, but
|
||||||
|
who cannot modify cinder services.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
There's a long comment in the `base policy definition file
|
||||||
|
<https://opendev.org/openstack/cinder/src/commit/fae0e8dcb430bfe2d00b5360c56aa2e936f5f78c/cinder/policies/base.py>`_
|
||||||
|
in the cinder code repository that gives a fairly precise description of
|
||||||
|
how the policy changes made during the Xena cycle would be continued into
|
||||||
|
Yoga. Unfortunately, however, as services have begun implementing Consistent
|
||||||
|
and Secure RBAC, some problems in the initial proposal have been identified,
|
||||||
|
resulting in a direction change for the effort [2]_. This means that the
|
||||||
|
above-mentioned strategy for cinder in the Yoga cycle [3]_ must be completely
|
||||||
|
revised.
|
||||||
|
|
||||||
|
The direction change affects cinder in the following ways:
|
||||||
|
|
||||||
|
* The "system-\*" personas are defined to act on the service itself (not
|
||||||
|
on project-owned resources) to the greatest extent possible. (In
|
||||||
|
Xena, these personas were envisioned to act as a cinder super-user and
|
||||||
|
hence be able to perform all operations, both on project resources and
|
||||||
|
on the system itself.)
|
||||||
|
* The "project-admin" persona is now intended to be an administrator (that
|
||||||
|
is, a representative of the operator--definitely not an end user) who can
|
||||||
|
perform admin type actions on project-owned resources (for example,
|
||||||
|
migrating a volume).
|
||||||
|
* A new "project-manager" persona is introduced. This is intended to be an
|
||||||
|
end user who has some extra privileges beyond those of a "normal" user
|
||||||
|
in a project. For example, a project-manager could be given the ability
|
||||||
|
to set a volume type as the default type for the project.
|
||||||
|
|
||||||
|
In Yoga, we'll do the following:
|
||||||
|
|
||||||
|
* The Cinder `Policy Personas and Permissions` document merged in Xena [4]_
|
||||||
|
contained forward-looking information about what would be done in Yoga.
|
||||||
|
Unfortunately, this is no longer accurate. The stable/xena version of
|
||||||
|
this document should be revised to describe *only* the Xena changes so
|
||||||
|
that operators aren't misled about the direction the effort is taking.
|
||||||
|
|
||||||
|
There is a patch up addressing this:
|
||||||
|
https://review.opendev.org/c/openstack/cinder/+/818696
|
||||||
|
|
||||||
|
* The Cinder `Policy Personas and Permissions` document in the Yoga
|
||||||
|
development branch will need to be revised:
|
||||||
|
|
||||||
|
* The range of actions allowed to the "system-\*" personas will be
|
||||||
|
restricted to operations on cinder services. These will be
|
||||||
|
"system-scoped" actions.
|
||||||
|
* The range of actions allowed to the "project-admin" persona will
|
||||||
|
allow this person to perform administrative operations on resources
|
||||||
|
owned by any project on which this person has the 'admin' role.
|
||||||
|
These will be "project-scoped" actions.
|
||||||
|
* The "project-member" and "project-reader" actions will likely be
|
||||||
|
unchanged from Xena, though they will be explicitly "project-scoped"
|
||||||
|
in Yoga.
|
||||||
|
* There will be some multiple scoped actions. Both system- and project-
|
||||||
|
personas should be able to list volume types, for example (though
|
||||||
|
only a system-admin should be able to create a volume type).
|
||||||
|
|
||||||
|
* Once the document has been revised, we'll be able to add a 'scope_types'
|
||||||
|
field to each policy rule.
|
||||||
|
|
||||||
|
* Additionally, we'll be able to update the check strings for all
|
||||||
|
policies.
|
||||||
|
|
||||||
|
* Ideally, when a project-admin makes a ``GET /v3/volumes?all_tenants=1``
|
||||||
|
call, for example, the response should include the volumes owned by all
|
||||||
|
and only the projects on which that project-admin has the 'admin' role.
|
||||||
|
For Yoga, we will allow anyone with the 'admin' role to see the volumes
|
||||||
|
in *all* projects (as is the case now). (See the discussion of "Listing
|
||||||
|
project resources across the deployment" [5]_ in the community goal
|
||||||
|
statement for why it's being done this way for Yoga.)
|
||||||
|
|
||||||
|
At this point, we will have completed Phase 1 [6]_ of the community goal.
|
||||||
|
This will allow cinder to ship with the oslo.policy configuration option
|
||||||
|
``enforce_scope=True`` in the Z release. (The importance of this is that
|
||||||
|
Phase 3 [7]_ of the community goal cannot be implemented until a service
|
||||||
|
requires ``enforce_scope=True``.)
|
||||||
|
|
||||||
|
We will plan to do Phase 2 [8]_ of the community goal during the Z
|
||||||
|
development cycle. See the community goal document for details.
|
||||||
|
|
||||||
|
As mentioned above, by completing Phase 1 in Yoga, we should also be in
|
||||||
|
a positon to complete Phase 3 during the Z development cycle.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
Do nothing. Despite all the work we did in Xena, this is still not really an
|
||||||
|
option, because it's not possible for some projects to use scoping and others
|
||||||
|
to ignore it while at the same time having consistent personas across projects.
|
||||||
|
So if we don't upgrade our policy definitions, we will block all OpenStack
|
||||||
|
clouds from being able to use Consistent and Secure Policies.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The ability to make various Block Storage API calls is already governed by
|
||||||
|
policies.
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Overall this should improve security by presenting operators a suitable
|
||||||
|
set of "personas" that will function consistently across project that they
|
||||||
|
can use out of the box instead of implementing their own.
|
||||||
|
|
||||||
|
Active/Active HA impact
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None, we already have to make calls out to keystone to validate tokens
|
||||||
|
and retrieve user privileges.
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None, other than doing the implementation work.
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
|
||||||
|
* rosmaita
|
||||||
|
* abishop
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
|
||||||
|
* tosky
|
||||||
|
* enriquetaso
|
||||||
|
* eharney
|
||||||
|
* geguileo
|
||||||
|
* whoami-rajat
|
||||||
|
* jobernar
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
* Update the Cinder *Policy Personas and Permissions* document in the
|
||||||
|
stable/xena branch.
|
||||||
|
* Update the Cinder *Policy Personas and Permissions* document in the
|
||||||
|
master for the Yoga policy changes described above.
|
||||||
|
* Add the appropriate ``scope_types`` to all policy rules.
|
||||||
|
* Update policy checkstrings to separate system policies from project
|
||||||
|
policies.
|
||||||
|
* Update all tests to reflect the above changes, adding new tests as necessary.
|
||||||
|
* Client changes to support system scope:
|
||||||
|
https://review.opendev.org/c/openstack/python-cinderclient/+/776469
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None, the required changes to complete Phase 1 merged long ago in Keystone
|
||||||
|
and oslo.policy.
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
* Continue to use the testing framework developed in Xena.
|
||||||
|
|
||||||
|
* We continue to have the stretch goal (mentioned in the Xena spec) to have
|
||||||
|
testing for secure RBAC in the cinder-tempest-plugin, but we do not
|
||||||
|
consider it a requirement for successful completion of this spec.
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
The primary user-facing documentation for Cinder is `Policy Personas and
|
||||||
|
Permissions` in the `Cinder Service Configuration Guide`.
|
||||||
|
|
||||||
|
Additionally, we expect that there will be more general documentation for
|
||||||
|
operators in the Keystone docs given the OpenStack-wide nature of this effort.
|
||||||
|
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
.. [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
|
||||||
|
|
||||||
|
.. [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
|
||||||
|
|
||||||
|
.. [3] https://opendev.org/openstack/cinder/src/commit/fae0e8dcb430bfe2d00b5360c56aa2e936f5f78c/cinder/policies/base.py#L193-L248
|
||||||
|
|
||||||
|
.. [4] https://docs.openstack.org/cinder/xena/configuration/block-storage/policy-personas.html
|
||||||
|
|
||||||
|
.. [5] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#listing-project-resources-across-the-deployment
|
||||||
|
|
||||||
|
.. [6] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-1
|
||||||
|
|
||||||
|
.. [7] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-3
|
||||||
|
|
||||||
|
.. [8] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-2
|
||||||
Loading…
Reference in New Issue
Block a user