Open Stack

Hey folks,

As I'm sure some of the cinder folks are aware, I'm updating cinder
policies to include support for some default personas keystone ships with.
Some of those personas use system-scope (e.g., system-reader and
system-admin) and I've already proposed a series of patches that describe
what those changes look like from a policy perspective [0].

The question now is how we test those changes. To help guide that decision,
I worked on three different testing approaches. The first was to continue
testing policy using unit tests in cinder with mocked context objects. The
second was to use DDT with keystonemiddleware mocked to remove a dependency
on keystone. The third also used DDT, but included changes to update
NoAuthMiddleware so that it wasn't as opinionated about authentication or
authorization. I brought each approach in the cinder meeting this week
where we discussed a fourth approach, doing everything in tempest. I
summarized all of this in an etherpad [1]

Up to yesterday morning, the only approach I hadn't tinkered with manually
was tempest. I spent some time today figuring that out, resulting in a
patch to cinderlib [2] to enable a protection test job, and
cinder_tempest_plugin [3] that adds the plumbing and some example tests.

In the process of implementing support for tempest testing, I noticed that
service catalogs for system-scoped tokens don't contain cinder endpoints
[4]. This is because the cinder endpoint contains endpoint templating in
the URL [5], which keystone will substitute with the project ID of the
token, if and only if the catalog is built for a project-scoped token.
System and domain-scoped tokens do not have a reasonable project ID to use
in this case, so the templating is skipped, resulting in a cinder service
in the catalog without endpoints [6].

This cascades in the client, specifically tempest's volume client, because
it can't find a suitable endpoint for request to the volume service [7].

Initially, my testing approaches were to provide examples for cinder
developers to assess the viability of each approach before committing to a
protection testing strategy. But, the tempest approach highlighted a larger
issue for how we integrate system-scope support into cinder because of the
assumption there will always be a project ID in the path (for the majority
of the cinder API). I can think of two ways to approach the problem, but
I'm hoping others have more.

First, we remove project IDs from cinder's API path.

This would be similar to how nova (and I assume other services) moved away
from project-specific URLs (e.g., /v3/%{project_id}s/volumes would become
/v3/volumes). This would obviously require refactoring to remove any
assumptions cinder has about project IDs being supplied on the request
path. But, this would force all authorization information to come from the
context object. Once a deployer removes the endpoint URL templating, the
endpoints will populate in the cinder entry of the service catalog. Brian's
been helping me understand this and we're unsure if this is something we
could even do with a microversion. I think nova did it moving from /v2/ to
/v2.0/, which was technically classified as a major bump? This feels like a
moon shot.

Second, we update cinder's clients, including tempest, to put the project
ID on the URL.

After we update the clients to append the project ID for cinder endpoints,
we should be able to remove the URL templating in keystone, allowing cinder
endpoints to appear in system-scoped service catalogs (just like the first
approach). Clients can use the base URL from the catalog and append the
admin project ID before putting the request on the wire. Even though the
request has a project ID in the path, cinder would ignore it for
system-specific APIs. This is already true for users with an admin role on
a project because cinder will allow you to get volumes in one project if
you have a token scoped to another with the admin role [8]. One potential
side-effect is that cinder clients would need *a* project ID to build a
request, potentially requiring another roundtrip to keystone.

Thoughts?

[0] https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac
[1] https://etherpad.opendev.org/p/cinder-secure-rbac-protection-testing
[2] https://review.opendev.org/c/openstack/cinderlib/+/772770
[3] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915
[4] http://paste.openstack.org/show/802117/
[5] http://paste.openstack.org/show/802097/
[6]
https://opendev.org/openstack/keystone/src/commit/c239cc66615b41a0c09e031b3e268c82678bac12/keystone/catalog/backends/sql.py
[7] http://paste.openstack.org/show/802092/
[8] http://paste.openstack.org/show/802118/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210128/625d7b48/attachment-0001.html>