This commit updates the policies for group snapshots to understand scope
checking and account for a read-only role. This is part of a broader series of
changes across OpenStack to provide a consistent RBAC experience and improve
security.
Change-Id: Id02cb45ecca32378a0a8b65589f21c64893d2c8e
This commit updates the policies for share types to understand scope checking
and account for a read-only role. This is part of a broader series of changes
across OpenStack to provide a consistent RBAC experience and improve security.
Change-Id: Id96bb3c7295dd2eae58a168fd5a265825c040a29
This commit updates the policies for share servers to understand scope checking
and account for a read-only role. This is part of a broader series of changes
across OpenStack to provide a consistent RBAC experience and improve security.
Change-Id: Ib6645980a84e911431862680161b48c4ff8ea494
This commit updates the policies for share snapshot instance export locations
to understand scope checking and account for a read-only role. This is part of
a broader series of changes across OpenStack to provide a consistent RBAC
experience and improve security.
Change-Id: I493f4e3bdca141b08ed8a6fbeb8b9d461e3d8118
This commit updates the policies for share snapshot locations to understand
scope checking and account for a read-only role. This is part of a broader
series of changes across OpenStack to provide a consistent RBAC experience and
improve security.
Change-Id: I6a7daaae66d103cf1435be275555777b51a251ab
This commit updates the policies for share replica locations to understand
scope checking and account for a read-only role. This is part of a broader
series of changes across OpenStack to provide a consistent RBAC experience and
improve security.
Change-Id: I2964f82844df47006e79c90d32f43174203f2aa6
This commit updates the policies for share instance export locations to
understand scope checking and account for a read-only role. This is part of a
broader series of changes across OpenStack to provide a consistent RBAC
experience and improve security.
Change-Id: I0cf9beed3c60fd790045580afa0c993c21e71d49
Allows set min/max share size that can be created in
extra_specs for each share_type.the share size will
be checked at API level as part of share create,
extend, shrink, migration_start. when manage share,
check it after get true size of share at manager layer.
new extra_specs keys are supported for set min/max
size of share.
'provisioning:max_share_size'
'provisioning:min_share_size'
Implements: blueprint share-size-limited-by-share-type
Change-Id: I5ce0fabf59bfca5ebaf0be5ffe9986e2b0480295
This commit updates the policies for share locations to understand scope
checking and account for a read-only role. This is part of a broader series of
changes across OpenStack to provide a consistent RBAC experience and improve
security.
Change-Id: Iaebbadea3ed153f19e7abb13d7d28ae3b6bb1fd9
This commit updates the policies for share
access rule metadata to understand scope
checking and account for a read-only role.
This is part of a broader series of
changes across OpenStack to provide a
consistent RBAC experience and improve
security.
Change-Id: Ie9fafd00f1a1888979fbce2a66af53613f8052c7
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This commit updates the policies for share access rules to understand scope
checking and account for a read-only role. This is part of a broader series of
changes across OpenStack to provide a consistent RBAC experience and improve
security.
Change-Id: I12026c7874620abb076df979f0492f6d1b8563fd
This commit updates the policies for services to
understand scope checking and account for a
read-only role. This is part of a broader series
of changes across OpenStack to provide a
consistent RBAC experience and improve security.
Change-Id: I340f63874af5783099ed6b353be61a2909829343
This commit updates the policies for security services
to understand scope checking and account for a read-only
role. This is part of a broader series of changes across
OpenStack to provide a consistent RBAC experience and
improve security.
Change-Id: I399a61691dad3a80c289c9f3f99f3c48be07846f
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
There was a traceback being included in the
error message body. This is unhelpful to
end users.
The error message that included the traceback
was for this corner case where the RBAC policy
isn't aligned with the internal "context_is_admin"
policy - an unlikely combination of decisions
that a deployer would make - nevertheless,
this is an opportunity for us to fix this
code path.
Change-Id: I888d684acac2133425f986ec7cef5e4f5cdcc5b6
Closes-Bug: #1917520
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Non privileged users of unrelated projects
must not be able to retrieve details of an
access rule. We can add a further check to
/share-access-rules APIs to validate that
the caller has access to the share that these
rules pertain to.
Change-Id: I0009a3d682ee5d9a946821c3f82dfd90faa886aa
Closes-Bug: #1917417
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
oslo policy handles the mapping of
credentials from a context object to values
that oslo policy cares about. This mapping
includes some deprecations and compatibility
handling code that we must take advantage of [1].
So, stop mapping context to policy values
on our end, and rely on oslo.policy handling
this for us.
enforce and authorize methods in policy.py
do the same thing, but with a subtle
difference. The "enforce" method doesn't
raise errors when unregistered policies are
invoked - this shouldn't ever be the case
for any policies written/maintained within
manila - however, we support API extensions
and don't dictate what must be done there. So
add docstrings to clarify that we shouldn't
invoke enforce, ever.
Also handle InvalidPolicyScope exceptions
and raise the oslo.policy library version
since some test enhancements have been
committed in the latest version.
[1] d3185debdb/oslo_policy/policy.py (L1077-L1096)
Change-Id: I069bf7143d6ff66b3dcdc34c9b52d48f5808481b
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Manila's RequestContext base class was
recently refactored to allow arbitrary
keyword arguments to be passed on to the
base Context class in oslo_context. This
was done so that we don't have to maintain
every new addition to Context within manila
code since that layer may change as the
middleware components (keystonemiddleware, for
example) evolve outside of manila.
During this refactor, "system_scope" was
inadvertently added as a separate keyword
argument, and it wasn't being passed to the
base class, causing system scoped users to
not be represented correctly in the API.
We can drop this parameter and allow it to
flow transparently through "kwargs".
Change-Id: I88b664c631eddced4ee1fcdf34cf05222cb73662
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
The profiler integration with the shared file system service(Manila)
allows to trace commands issued using both manila-client and
openstack-client.
Note that osprofiler should be run from admin user name & tenant.
Closes-Bug: #1915116
Change-Id: Ic16bc3cb03b851003c189450b398f8dd5dde8160
*) Add osprofiler wsgi middleware
This middleware is used for 2 things:
1) It checks that person who want to trace is trusted and knows
secret HMAC key.
2) It start tracing in case of proper trace headers and add
first wsgi trace point, with info about HTTP request
*) Add initialization of osprofiler at start of serivce.
You should use python-manilaclient with this patch:
https://review.opendev.org/#/c/769731
Run any command with --profile SECRET_KEY
$ manila --profile SECRET_KEY create NFS 1 --name <share> \
--description <share_description> --share-network <network> \
--share-type default
# it will print <Trace ID>
Get pretty HTML with traces:
$ osprofiler trace show --html <Trace ID> --connection-string \
<connection_string> --out <output.html>
e.g. --connection-string can be redis://localhost:6379
Note that osprofiler should be run from admin user name & tenant.
Implements: blueprint manila-os-profiler
Change-Id: I3bce1f04d1cfebfacd78ed135a949a068c78987d
This patch fix a sqlalchemy object copy made in the driver
that can raise a 'DetachedInstanceError' exception, depending on
changes made in the DB model. A simple copy is being made instead, to
have a new share object with share server information inside it.
Change-Id: I5fef50a17bc72ba66a3a9d6f786742bcb5745d7b
Signed-off-by: Douglas Viroel <viroel@gmail.com>
These policies were deprecated in Stein and flagged
for removal in Train. Now that we're in the Wallaby
development cycle let's remove them.
Depends-On: I2a647fd5871ef6bb7d1ab45db893a44a560bed72
Change-Id: I6e7608be57de8987117f3f4ace018a7eb91c8bd2
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
python documentation recommends the
use of the requests package when performing
http requests. We could simplify our unit
test interface that performs HTTP requests
by replacing the use of http_client.HTTPConnection
with requests.
[1] https://docs.python.org/3/library/http.client.html
Change-Id: I3dd1f836a3cb2b4d36ff3fbe6f0258f4b0e0ba71
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
RequestContext has a helpful "from_environ"
method that can handle all possible combinations
of auth information users can send our way
when manila is deployed with its Keystone auth
middleware. We could switch to that, so that
we don't have to maintain support for the
full list of current and deprecated auth
configuration options in our auth
middleware.
While we're there, we can also update the
"to_dict" and "from_dict" methods in manila's
context class to match the information we need.
Change-Id: I5d554caf82a1fc4f1dcfede3ea61159ddaeb342e
Closes-Bug: #1602081
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Some of the response parameters for the
/shares APIs were either incorrect or
out of date. These inconsistencies
were discovered by Ashley Rodriguez
when working on the openstacksdk
integration for these APIs.
Change-Id: I475a7e4df2ee6924699b97c196f1958d4885c01d
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs.
Fix the docs to indicate that.
Also fix up a few quota parameters that use
project_id in a different place in the API path.
Change-Id: I24b32c8521805a7d67d512d36d644c0f07c532ea
Implements: bp remove-project-id-from-urls
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
A few releases ago, service types were standardized
across OpenStack [1] and manila's service type was
recommended as "shared-file-system" [2]. Tools were
meant to look at the service-types-authority [3]
and os-service-types repository [4] to find a list
of standard service type names for various first
party OpenStack services.
The openstacksdk currently relies on the service
type to be "shared-file-system" [5], so let's set
one up in devstack, to aid contributors working on
openstacksdk.
It is desirable to have all clients to initially
look for the standard service type name in the
cloud's service catalog, and fall back to the
legacy name ("sharev2") in environments that
call the v2 API that.
[1] https://specs.openstack.org/openstack/service-types-authority/
[2] https://service-types.openstack.org/service-types.json
[3] https://opendev.org/openstack/service-types-authority
[4] https://opendev.org/openstack/os-service-types
[5] f4dd6fe5fd/openstack/_services_mixin.py (L71-L72)
Change-Id: I6a1ada102a40f3e83fe8e5287856d01dd137ea95
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
As of API version 2.60, a project_id is no
longer needed in the API URLs. We can stop
devstack from setting up an endpoint with
project_id in it.
Create a "sharev2_legacy" endpoint that
contains the project_id for testing the
compatibility with the older style of URLs.
Change-Id: I25aeb1b6dd1a4150c6e542e29b7d43e18d9ad94c
Implements: bp remove-project-id-from-urls
Depends-On: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
Manila APIs have had the requirement to include
project_id in the URLs since the very beginning.
This comes from an old assumption that our APIs
would be differentiated per-tenant on the cloud,
and we would allow different kinds of API endpoints
(public, admin, internal, etc). While it is possible
to set up different endpoints against the API
service, the same and complete API is exposed at
each of these endpoints.
We don't _need_ the project_id information that
we receive in the URL for any of our APIs to
function. We rather authorize tenants by gathering
information from the Identity service (Keystone)
and wrapping that into a RequestContext object
that we then rely on to ensure namespace isolation.
Removing the requirement for "project_id" simplifies
our API endpoint structure in the service catalog
as well as provides a way for system scoped users
to interact with manila without having to declare
their project.
In order to make project_id optional in urls, the
possible values of project_id have to be constrained.
This change introduces a new configuration option
so deployers may control that. This configuration
option defaults to accepting UUIDs with and without
dashes.
Since manila can be used in standalone deployments
without the need for Keystone, this change introduces
a noauth middleware that can work without project_id
in the URL paths.
The API version has been incremented to signal this
change to end users. When 2.60 is available, deployments
may drop "project_id" in the service catalog endpoint
for Manila and end users applications can stop needing
it as well (if they don't already rely on the service
catalog for this data).
APIImpact
Implements: bp remove-project-id-from-urls
Change-Id: I5127e150e8a71e621890f30dba6720b3932cf583
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
This change makes healtcheck middleware enabled by default, so that
operators can use the middleware to monitor service availability for
various purpose like healthcheck by load balancers.
Change-Id: I47e65d23ebfe310643896e1de3396cd627a3def3
