From de4308f4a756da3c189ea77663715ae16a5ea215 Mon Sep 17 00:00:00 2001 From: Brian Rosmaita Date: Fri, 17 Sep 2021 10:07:51 -0400 Subject: [PATCH] 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 --- specs/xena/s-rbac-ready.rst | 74 +++++++--- specs/yoga/s-rbac-ready.rst | 268 ++++++++++++++++++++++++++++++++++++ 2 files changed, 325 insertions(+), 17 deletions(-) create mode 100644 specs/yoga/s-rbac-ready.rst diff --git a/specs/xena/s-rbac-ready.rst b/specs/xena/s-rbac-ready.rst index 7924037d..9b1c75e9 100644 --- a/specs/xena/s-rbac-ready.rst +++ b/specs/xena/s-rbac-ready.rst @@ -8,7 +8,7 @@ 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 Consistent and Secure RBAC effort. @@ -45,9 +45,42 @@ Some examples: Proposed change =============== -Make changes to cinder so that it can recognize the scope of a token and -add policy checkstrings to implement the "personas" described in -https://review.opendev.org/c/openstack/cinder/+/763306 +Make changes to the cinder default policies so that the default configuration +recognizes the keystone 'reader' role and treats it appropriately. This will +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 + `_ + 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 +`_ for more details. + Alternatives ------------ @@ -135,24 +168,22 @@ Work Items validate tests of the default policies. 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 * 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 Initial test patches: 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 - `_.) - Dependencies ============ @@ -162,9 +193,18 @@ None, the required changes in Keystone and oslo.policy merged long ago. Testing ======= -* Because of the complexity of the policy configuration, testing will be - done mostly in the cinder-tempest-plugin so that each persona can be - tested against a real Keystone instance. +* We'll need a flexible testing framework because we are going from 2 + personas in Wallaby to 3 personas in Xena to 5 personas in Yoga, and + 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 ==================== diff --git a/specs/yoga/s-rbac-ready.rst b/specs/yoga/s-rbac-ready.rst new file mode 100644 index 00000000..9e0390e7 --- /dev/null +++ b/specs/yoga/s-rbac-ready.rst @@ -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 +`_ +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 +`_ +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