Add file to the reno documentation build to show release notes for
stable/wallaby.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/wallaby.
Sem-Ver: feature
Change-Id: I1a6a99bb19181cd92ca5e328eba846c603425654
This just makes a trivial typo fix in the minor-code-changes doc.
Change-Id: If0093316c393b09ed4d936d2625b2d27024bfdbc
Co-Authored-By: Abhishek Kekane <akekane@redhat.com>
This restricts all metadef resource manipulation to admin-only, but
still allow users to see everything. There are multiple low-grade
security issues with the metadef API, detailed in the related bug.
Restricting resource manipulation to admin-only solves most of these
concerns.
SecurityImpact
Depends-On: https://review.opendev.org/c/openstack/tempest/+/780108
Change-Id: I333c58e73c202c1f523030e54e03f2868459b595
Related-Bug: #1916926
Provide some literature on what we introduced for operators in wallaby,
how they can configure it, and actions we recommend they take. Since
this marks the point at which we consider the feature implemented,
this also removes the legacy-rbac job and makes the secure-rbac job
voting.
Implements: blueprint secure-rbac
Change-Id: I8f980cf7731d26b92b5392fdada21e5be0f541c4
The wait_for_copying() helper will exit the loop if the *last*
store is found in the list, instead of *all* of them. This technically
works if the stores are processed in the same order we are checking,
but it's fragile and likely to fail in confusing ways.
This makes us only exit if all of them are present.
Change-Id: I8d9ba50f46e22b6740fdbdec6f8ef7c61dddbcf1
At one point, these policies were used to protect actual task API
endpoints. Since then, they have also been used internally within
glance when spawning a task on behalf of the user for long-running
operations (like import).
These policies should not apply to the internal usage, as doing so
prevents the operator from setting them to restrictive values in order
to provide granular access to some roles. In the future we will fix
that by moving those checks out of "the onion" and into the task API
operations themselves, thus decoupling the internal and external uses.
This adds documentation and scope definitions for these policies, as
well as deprecates the "modify_task" policy which is never used and
will be removed in the future. Control over the actual tasks API
remains coarse with the "tasks_api_access" policy until a future
release completes the above decoupling.
Implements: blueprint secure-rbac
Change-Id: I70a58acd78053b54187dba8e35273366f14c47a4
We've broken basic policies into granular checks with simple names and
we use them to construct more complex checks. In that process we
accidentally added some additional nesting to two of the check strings,
which isn't necessary.
This commit updates the check strings to remove an extra set of
parenthesis.
Change-Id: Iafa37d64a9779a3b646c34f328c62dfd6cd3e7f3
This commit updates the policies for image actions to use default roles
available from keystone. Specifically, we're updating the defaults to
user project-member and project-reader personas. The project-admin
persona is still reserved for administrative APIs access for system
administrators/operators. This will remain the case until we can
refactor portions of glance to make it easier to implement system-scope.
NOTE:
Glance is implementing Secure RBAC as EXPERIMENTAL in Wallaby, so to
enable it operator needs to set ``glance-api.conf [oslo_policy]
enforce_new_defaults=True`` and ``glance-api.conf
enforce_secure_rbac=True``
Implements: blueprint secure-rbac
Change-Id: If0c456617a9e17c006a6ffe2a83f4a73b53da3d0
This fixes the ImageStub in the test_cache_middleware module, which
does not implement enough of a real image to be usable in the next
patch where we need to dict() it. This does that refactor ahead of
time so that patch is smaller.
Change-Id: Ie86e0ae16c81fb7aa353dd350f0a4f3cf852d893
This commit updates glance's zuul configuration to tack on a job
dedicated to protecting API authroization. The tests for this job live
in glance-tempest-plugin and they currently test full support for
project-reader and project-admin against the images API.
Future changes will update the policies in glance to consume
system-scope and additional test coverage will be added to
glance-tempest-plugin. But, until that happens, having protection
testing as part of the check and gate jobs is vital to ensuring we don't
inadvertently expose sensitive information or APIs to users.
This level of testing will also be useful in the future if we decide to
refactor authorization logic out of various parts of glance and into a
consistent layer.
Depends-On: https://review.opendev.org/c/openstack/glance-tempest-plugin/+/775742
Change-Id: Iddee8144fb21b7ac2dec4e7fbc62c132c186fa89
This enables the g-api-r service in devstack, which allows tempest
to run the remote import test, causing it to stage and import an
image across two different workers. Note we disable it for the
standalone mode, since devstack does not support starting another
standalone glance.
Depends-On: https://review.opendev.org/c/openstack/devstack/+/770487
Depends-On: https://review.opendev.org/c/openstack/tempest/+/770520
Change-Id: Ica715fc1922f4b36dd0bb008ef6706b86115ec05
As noted in previous discussions, glance should clean its staging
directory on startup. This is important for scenarios where we
started an import operation, but failed in the middle. If, when we
recover, the image has already been deleted from the database, then
we will never remove the (potentially very large) residue from disk
in our staging directory.
This is currently a problem with web-download, but will also occur
with glance-direct once we have the non-shared distributed import
functionality merged.
Closes-Bug: #1913625
Change-Id: Ib80e9cfb58680f9e8ead5993dc206f4da882dd09
This adds some text to the documentation about configuring the import
mechanism, including details about shared vs. local staging
directories. It also clarifies that *all* import methods require the
staging directory to be configured, as well as cleans up some
single-store-specific wording in this area.
Related to blueprint distributed-image-import
Change-Id: I726abe5d1104510e8da0e94f90f2b36d43b82cbe
This implements distributed image import support, which addresses
the problem when one API worker has staged the image and another
receives the import request.
The general approach is that when a worker stages the image, it
records its self-reference URL in the image's extra_properties. When
the import request comes in, any other host will proxy that HTTP
request direct to the original host instead of trying to do the import
itself.
Implements: blueprint distributed-image-import
Change-Id: I12daccb43c535b579c22f9d0742039b2ab42e929
Currently it is not possible to configure the staging directory
URI of the functional workers. We need to be able to do that in order
to enable the stage cleaning behavior. Right now, they're all sharing
/tmp/staging, which will cause workers to conflict while running in
parallel. This causes them to use their private test directory,
which may also help some other spurious failures due to interaction.
Related-Bug: #1913625
Change-Id: Ic2ac2a528206c50c38e948a096daf9eb8e5eb715
This informs operators of glance's support status for secure RBAC as of
the Wallaby release. Eventually, this message will be removed when
glance adopts more support for secure RBAC personas.
This also forces glance to fail if it's configured improperly. This is
done to explicitly prevent ambiguity with authoritative decisions.
Related: blueprint secure-rbac
Change-Id: I06293de08dd3fdfbd60b9a65501d1198f40ff434
This adds a method in glance.context that will give us a
keystoneauth1 client, authorized with the user's token, suitable for
calling directly to other services.
Related to blueprint distributed-image-import
Change-Id: I71ed8c80939b4cfab6a081c2f8cde63299fc7893