As per the revised SRBAC community goals, glance service is now
switching to new defaults by default hence removing the deprecated
``enforce_secure_rbac`` option which is no longer needed.
The ``enforce_secure_rbac`` option was introduced EXPERIMENTAL in
Wallaby release for operators to opt into enforcing authorization
based on common RBAC personas.
Related blueprint secure-rbac
Change-Id: I273527c85d30c1c09c086c73c892aaa6d127df6b
currently `role:admin` is explicitly used in many policies,
which makes it harder to globally override it to e.g.
`role:admin and is_admin_project:True`, such change would require
many policies to be overrided explicitly as well.
This patch swaps `role:admin` for `rule:context_is_admin`, allowing for
easier and more centralized override of 'adminness' meaning.
Change-Id: I2ba0ce300bcd85c1aca43c166a41fb331ab9dbef
In Xena we have mangaed to move all policy checks to API layer,
now removing the dead code from policy and authorization layer
NOTE: Some of the code is still being used from policy layer,
hence keeping it there only at this moment.
Change-Id: Ibee749cde20687d8c243cf84ae80b4de67d8ef3d
It was observed that md-tag-create-multiple
(/v2/metadefs/namespaces/{namespace_name}/tags) API overwrites
existing tags for specified namespace rather than creating new one
in addition to the existing tags.
This patch resolves the issue by introducing a header 'X-Openstack-Append'
which on being True will append the new tags to existing ones and
if False will continue to overwrite the tags.
Implements: blueprint append-tags
Closes-Bug: #1939169
Change-Id: I29448746b14c542e5fbf0283011968ae1516642e
The oslopolicy-sample-generator wraps strings in double quotes, which
breaks with the glance sample policy file since it's using double quotes
to evaluate strings.
This commit fixes the issue so that we're using single quotes in the
check strings so oslo.policy can wrap them with double-quotes and it
won't break yaml parsers.
Change-Id: I4f4553d91e58047c05ea853a8eb3764376338a45
As part of the new policy work, all of the defaults for
policies were changed and warnings about it are being emitted
constantly in the logs. We can suppress these for now until we are
enforcing new defaults.
This also suppresses policy deprecation warnings during tests to avoid
filling the console with warning messages.
Change-Id: Ib2a7a2ed8bcadbb6a002cfa4b34c70910faa4f00
As noted by lbragstad, we need to make ImageTarget contain a member
field so that we can generically apply policies and be able to
properly include images for which we are a member. This was hacked
into place for ImageRepoProxy.get() but in order to apply it generally
to listing and other ops, we need to formalize that.
Partially-Implements: blueprint policy-refactor
Change-Id: I92d3792602a69922078d109095ad8ac9afc89d14
This includes a change to catch Forbidden and convert to NotFound.
The previous Forbidden handler was not only correct (it shoud hide
the permissions error with "not found") but it was actually dead code,
since the DB was performing its own checks and would never raise
Forbidden.
This also includes a change of the default policy for get_images
to include the other states, like get_image does. I think this was
just an oversight in the original RBAC patches, which didn't matter
because they weren't really being honored strictly.
Partially implements: blueprint policy-refactor
Change-Id: I70100cd7f01da803e9740cea1f7ce7ae18ad6919
This makes ImageTarget integrate the aliasing of project_id to owner,
avoiding the need to do it every time we use ImageTarget. This will
simplify subsequent patches.
Change-Id: Ia9998f638546ac36cd200f0c9002eadd18b71094
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 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
The oslo.policy's Enforcer() object will transpose authorization
information from oslo.context RequestContext objects if you pass one
to enforce()[0].
This commit simplifies the enforcement code in glance by letting
oslo.policy handle the translation instead of glance. This allows us to
remove the to_policy_values() method maintained in glance since it's no
longer used.
[0] 775641a5fc
Related: blueprint secure-rbac
Change-Id: Ie7f9a9201361c56e0f0a289ef93443b9e277357c
Now that we're setting scope_types on policies, oslo.policy will throw
an InvalidScope exception if configured to do so. We should handle this
when we call enforcement so that we can bubble up an appropriate
Forbidden exception to the user.
Related: blueprint secure-rbac
Change-Id: I50fe718d3b50af0d662fda6fa0fbd3e29783e063
These policy check strings model uniform, consistent personas that we'd
like to implement across OpenStack APIs. Doing this consistently will
improve user experience for end-users and operators who are struggling
to maintain drift in RBAC implementations across OpenStack.
Subsequent patches will use these check strings in new policy defaults.
Additionally, future patches will introduce check string for
system-personas when glance is a better position to adopt system-scope
for administrative APIs.
Related: blueprint secure-rbac
Change-Id: Id09ad3d3a6e96d9d77a9f8a43c755b1b6b9c9b7d
We added compatibility handling in I11e482354725ed74629dcaa9f2b7f229a60aa2a8
for the move of some classes from collections to collections.abc and
incompatibility between older and newer python versions.
Now that we have dropped the older versions, all supported versions
have the classes under collections.abc and we can drop the special
handling.
Change-Id: I6d7cb25700ed552fbf82c09b6eea688ebee0dab2
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Now that we no longer support py27, we can use the standard library
unittest.mock module instead of the third party mock lib.
Change-Id: I44e7b6f76e2d12f620ec602afc77ce11ba6b9d9a
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Several Metadata Definition delete APIs do not have RBAC. This
patchset add policy enforcment to the following APIs:
- `Delete namespace`
- `Delete object`
- `Remove resource type association`
- `Remove property definition`
- `Delete tag definition`
- `Delete all tag definitions`
The following actions are enforce and added to the policy.json:
- `delete_metadef_namespace`
- `delete_metadef_object`
- `remove_metadef_resource_type_association`
- `remove_metadef_property`
- `delete_metadef_tag`
- `delete_metadef_tags`
Most other APIs have policy enforcement, so the ones above should as
well. Without adding policy enforcement for the above APIs, all roles
can peform the delete APIs noted above.
Change-Id: I8cd6eb26b0d3401fa4667384c31e4c56d838d42b
Closes-Bug: #1782840
Co-Authored-By: julian.sy@att.com
Instead of a default policy.json file, policy defaults are now defined
in code. An operator need not supply policy.json data except to the
extent they want to override the defaults. Currently an empty
policy.json is still shipped because it is expected by devstack, but
this can be removed later. A sample policy.yaml file can be generated
using the genpolicy tox environment.
This partly fulfils the requirements of the policy in code goal[1].
However, because policies don't map 1:1 with APIs, it will not be
possible to fully document the policies until changes are made in how
policies are applied as proposed in https://review.opendev.org/528021
Due to the fact that existing policy files may rely on a rule named
"default" to specifiy policies not explicitly listed in the policy.json
file, all policies that are not admin-only by default now default to
"rule:default", so that the "default" rule will continue to apply to
those policies that are not listed in policy.json.
To ensure that this yields the expected policy in a standard
policy-in-code config file, the default value of the "default" rule is
now the empty string "". This is a change; between the Queens release
and now the default was set to "role:admin" to match the value specified
in the default policy.json file. An installation relying on both the
"default" rule for some policies and the default value of the default
rule may end up with a more permissive policy after upgrading. It's
likely that no such policies exist in the wild, because prior to the
Queens release the default value for the "default" rule was "@" (allow
all requests), so anybody relying on this rule will surely have
specified it explicitly in their policy.json.
Policies whose default is "role:admin" no longer use the "default" rule.
Therefore existing policy.json files that rely on the "default" rule for
those policies, and who have specified a value for the "default" rule
that is more permissive, will result in a more restrictive policy after
upgrading. It is unlikely that any of these policies exist in the wild
either.
[1] https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html
Change-Id: I8d1ccf5844078cc0b1652fb1130794daf07cedbc
The use of ABC classes directly from collections has been deprecated in
3.x versions of Python. The direction is to use the classes defined in
collections.abc. Python 2.7 does not have this, but Python 3.8 will be
dropping the backwards compatibility to use the old location.
Six also does not have support for this yet, so in the mean time to make
sure we don't run into issues as folks try to move to 3.8, and to get
rid of deprecation warnings in logs, this handles importing from the
preferred location and falls back if it not available.
Change-Id: I11e482354725ed74629dcaa9f2b7f229a60aa2a8
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We would like to fully remove mox from the test tree. Even for tests
that don't use mox's validation, many of them are using the symbol
patching with self.stubs.Set. We can do the same thing with the
monkeypatch fixture instead.
This introduces self.stub_out to nova/test.py and an example of what a
stubs => stub_out change would look like.
The teardown function in the converted test was removed at the same
time, as those should no longer be used.
Part of the mox community goal for Rocky.
Change-Id: I8f471ff8fee600ebb4e8907bf240007b7b4fe59f
Signed-off-by: Chuck Short <chucks@redhat.com>
Added new boolean column "os_hidden" in images table. Images where
"os_hidden" = True will be omitted from the image list presented
to the user. This will apply to all image visibilities. However,
the images will continue to be discoverable. User can use
filter "os_hidden=true" in GET v2/images call to see all hidden
images.
Implements: blueprint hidden-images
Change-Id: If8f02ca94fdb8e1ac7a81853cd392988900172d1
There are two methods to create images:-
Method A)
POST /v2/images
PUT /v2/images/{image_id}/file
Method B)
POST /v2/images
PUT /v2/images/{image_id}/stage
POST /v2/images/{image_id}/import
The traditional image upload API (PUT /v2/images/{image_id}/file)
uses 'upload_image' policy which is same for
Method B (POST /v2/images/{image_id}/import)
image-create-via-import(new API for image create) API.
The long term goal is to make users use method B to create images
and cross services to use Method A until changes are made to
use Method B.
To restrict normal users from using Method A to create images both
these APIs (/v2/images/{image_id}/file and /v2/images/{image_id}/import)
should have a distinct policy.
This patch move the 'upload_image' policy check from imge.set_data()
to the controller and not introduce any new policies at this point
for import API call (POST /v2/images/{image_id}/import)
on the theory that an operator can stop import by restricting the
'image_create' policy. And also this fix will not change the semantics
of the 'upload_image' policy from the operator perspective.
Closes-Bug: #1732141
Change-Id: Icc62add5f8d48549aac94c8058d66d6b77b56d41
This is required because oslo_policy's 'enforce' method expects a dict-like
object as its second argument.
Change-Id: I9187b6805d3b2cd351189e34dd2f9db3158f6b8d
Closes-Bug: #1720354
Our policy.json default value was changed from everybody to
"role:admin". this change will align the code with the
default config file provided for clarity and consistency.
Change-Id: I60228949c0288ef5f3ce71c427e4d62781cdd56b
This change replaces the existing boolean 'is_public' column for
the 'images' table with enum 'visibility' column featuring the
four explicit visibility values - public, private, shared,
and community.
This change also implements and enables all backend code to
utilize the new values.
Co-Authored-By: Timothy Symanczyk <timothy_symanczyk@symantec.com>
Co-Authored-By: Dharini Chandrasekar <dharini.chandrasekar@intel.com>
Implements: blueprint community-level-v2-image-sharing
Closes-Bug: #1394299
Closes-Bug: #1452443
Depends-On: I6e3268f3712cbc0aadb51d204c694023b92d55a5
Change-Id: I94bc7708b291ce37319539e27b3e88c9a17e1a9f
From: https://review.openstack.org/#/c/309346/
"
I investigated the behaviour of the policy file when various policies
are removed.
A completely empty policy file will return a 403 Forbidden. As the user
will not match with any of the policies.
However, because glance has the policy ``default: ""``. It means that
any policy that is not explicitly stated in the the policy.json, is
by default usable by any member. I think that the ``default`` option
is a potentially bad thing to have in the policy.json file, due to the
ability to give permissions without explicitly stating it.
"
Therefore we should change ``"default": "",`` to ``"default":
"role:admin",``. To make sure that members don't inherit policies that
they shouldn't in the future. From a operators perspective it should be
more secure to have an opt-in rather than opt-out.
Change-Id: I57f9d4791126360079a941c1ff4cb2bbb86298d5
Closes-Bug: 1593177
Image members CRUD doesn't generate notifications which
is impacting searchlight service by not having latest
changes to Image memberships.
If you create an image and later change its members,
the members are not updated via notifications.
You have to run the index sync again to get the updated
member list.
See: https://bugs.launchpad.net/searchlight/+bug/1490697
Membership information is critical for horizon filtering.
Typically, a person is allowed to view an image under the
following conditions:
1) The image is owned by the project I am currently logged into.
2) The image is public
3) The image is owned by another project which has added me
as a member and I have accepted membership to it.
Without current membership information, 3) above is not possible.
See: https://bugs.launchpad.net/searchlight/+bug/1491085
Change-Id: Ia56e42d3d8da36cfa419d5c3c7d69c9ccf8974fd
Closes-Bug: #1441453
This change:
- Adds oslo.policy to the requirements list
- Accounts for changes in Enforcer initialization
- Accounts for changes to config options
- Removes incubated version of oslo.policy
- Updates the in-tree etc/config files
UpgradeImpact
Partially Implements Blueprint: graduate-policy
Change-Id: I5acb1e0f809098991f05ca3b6d78d4d88d98f2db
Previously, every call to policy.enforce passed an empty dictionary as
the target. This prevents operators from using tenant specific
restrictions in their policy.json files since the target will always be
an empty dictionary.
If you try to restrict some actions so an image owner (users with the
correct tenant id) can perform actions, the check categorically fails
because the target is okay is an empty dictionary. By passing the
ImageTarget instance wrapping an Image, we can properly grant access to
the image owner(s) based on tenant (e.g., owner:%(tenant)). Without this
fix, the only check that actually works in glance is a RoleCheck (e.g.,
role:admin).
Partial-bug: 1346648
Implements: blueprint pass-targets-to-policy-enforcer
Change-Id: Id914c478ca7c4dfde3f08028d8b70c623f26b6e9
Currently image data cannot be removed synchronously for an image that
is in saving state. And when, the upload operation for such an image is
completed the operator configured quota can be exceeded.
This patch fixes the issue of left over chunks for an image which was
deleted from saving status. However, by the limitation of the design we
cannot enforce a global quota check for the image in saving status.
This change introduces a inconsonance between http response codes of
v1 and v2 APIs. The status codes which we will now see after the upload
process completes on an image which was deleted mid way are:
v1: 412 Precondition Failed
v2: 410 Gone
SecurityImpact
UpgradeImpact
APIImpact
Closes-Bug: 1383973
Closes-Bug: 1398830
Closes-Bug: 1188532
Change-Id: I47229b366c25367ec1bd48aec684e0880f3dfe60
Signed-off-by: Zhi Yan Liu <zhiyanl@cn.ibm.com>
oslo_config was moved out of the oslo namespace in oslo.config>=1.6.0.
Related-to: blueprint drop-namespace-packages
Change-Id: I30ecbf8f9de77496fcb643c7ad9738d79ad359f0
Added new rule in policy.json and applied that rule to
'download_image' policy.
For example,
"restricted": "not ('test_key':(test_key)s and role:_member_)"
"download_image": "role:admin or rule:restricted"
So if 'download_image' policy is enforced then in above case only admin or
user who satisfies rule 'restricted' will able to download image. Other users
will not be able to download the image and will get 403 Forbidden response.
In addition, delete property access should be restricted for other users
so that they will not be able to delete the property of the image.
[test_key]
create = admin,member
read = admin,member,_member_
update = admin,member
delete = admin,member
Added new method to create dictionary-like mashup of image core and custom
properties.
Modified v1 and v2 api to add download restriction.
Modified logic of caching to restrict download for v1 and v2 api.
DocImpact:
Need to add new rule in policy.json
"restricted": "not ('test_key':%(test_key)s and role:_member_)"
blueprint: restrict-downloading-images-protected-properties
Change-Id: I05bad0441952150bd15b831ac1b1a0bb9ae79c74
Change I0b406e4662cfd3cb496b71be77ad10a90c178baa introduces a new
class TaskStub. This class is designed to be a subset of what a
task is in the domain layer: it doesn't contain input, message and
result. TaskStub should be used when listing tasks in order to avoid
extra-overhead of transporting these text fields.
As a result, the TaskDetails introduced by change
I0b406e4662cfd3cb496b71be77ad10a90c178baa doesn't need to exist.
With this patch, the domain layer contains Task and TaskStub instead
of Task, TaskStub and TaskDetails.
partially implements bp async-glance-workers
Change-Id: I2a20b0c5033c6920749370355c2d672dec707c28
Partial Task patch, Id I4fbadc9a97e3147128c7c733384c7bb50918806f
removed the result and message vars of the Tasks class. However,
the succeed and fail methods were using those to update them
respectively. This patch introduces a new TaskStub class which
enables the PartialTask functionality without looking result
and message attrs of the Task class.
Fixes bug 1284975
Change-Id: I0b406e4662cfd3cb496b71be77ad10a90c178baa
- partial-task: Task that includes all the values except the 'Text'
columns(input, result & message).
- This patch is to have the database to return a partial-task list on users
invoking 'GET /v2/tasks'.
- Returning list of partial tasks will help in reducing the response time when the
user queries for the list of tasks.
- This patch also includes changes for making implementation and return values of
display task detail (GET /v2/tasks/{task_id}) and list tasks (GET /v2/tasks)
more explicit.
partially implements bp async-glance-workers
Change-Id: I4fbadc9a97e3147128c7c733384c7bb50918806f
Some of tests use different method of assertTrue(isinstance(A, B)) or
assertEqual(type(A), B). The correct way is to use assertIsInstance(A, B)
provided by testtools.
Change-Id: Ia8d38f73c159c7ef943a8f6cfe72b945cc493947
Closes-bug: #1268480
Remove the add and save method's return statement in the
ImageMemberRepo class, as the same as ImageRepo class. Also
modify authorization.py and policy.py and the related unittest.
Closes-Bug: #1254210
Change-Id: I472cd15af8648beea10abc595e905618091f3dab
This commit makes the glance code base E125 and E126 compliant :
* E125 continuation line does not distinguish itself from next logical line
* E126 continuation line over-indented for hanging indent
Change-Id: I7120149bedb665fb66320498fe98948602a6cd52
Closes-bug: #1263437
- add REST API layer for async worker(tasks) to
support tasks operations.
- update to include sparse task for tasks.index
- add domain proxies for handling authorization,
policy enforce, notification while processing
task requests.
- add Task domain entity and TaskFactory to create
new Task domain entity objects.
- add integration test for testing tasks api
Co-authored-by: Fei Long Wang <flwang@cn.ibm.com>
Partially implement blueprint async-glance-workers
Change-Id: I072cbf351c06f59a7702733b652bfa63e5abbaa6
Includes:-
- Domain Task class
- Domain TaskFactory class
- DB TaskRepo class
- Necessary proxy classes for all of the above
- Tasks related exceptions
- Unit tests as applicable
Partially implement blueprint async-glance-workers
Change-Id: I619224bcc55b62303f3539454649528f2edc6e9d
Related to bug 1250918
There currently exists no check in set_data function for glance
api v2 in the policy layer. This patch adds upload_image policy.
DocImpact
Change-Id: Ibccc78f8bccff3baa5aca574cf17bd14c5403ca2
Zuul