In HTML documents with openstackdocstheme, vertical lines are shown at the left side for literal blocks. Indented blocks are considered as literal blocks in ReST text. Unnecessary indented blocks are found in the glance document and it leads to blocks with unexpected vertical left lines and sometimes with unexpected fonts like [1]. Unexpected literal blocks are cleanup. This commit also converts Definition lists in user/formats.rst and user/common-image-properties.rst into the proper way in ReST text. [1] https://docs.openstack.org/glance/latest/user/formats.html#container-format Change-Id: I1b026f919bb22a59d23e3bb93bb7919d202a62fc
5.8 KiB
Policies
Glance's public API calls may be restricted to certain sets of users using a policy configuration file. This document explains exactly how policies are configured and what they apply to.
A policy is composed of a set of rules that are used by the policy "Brain" in determining if a particular action may be performed by the authorized tenant.
Constructing a Policy Configuration File
A policy configuration file is a simply JSON object that contain sets of rules. Each top-level key is the name of a rule. Each rule is a string that describes an action that may be performed in the Glance API.
The actions that may have a rule enforced on them are:
get_images
- List available image entitiesGET /v1/images
GET /v1/images/detail
GET /v2/images
get_image
- Retrieve a specific image entityHEAD /v1/images/<IMAGE_ID>
GET /v1/images/<IMAGE_ID>
GET /v2/images/<IMAGE_ID>
download_image
- Download binary image dataGET /v1/images/<IMAGE_ID>
GET /v2/images/<IMAGE_ID>/file
upload_image
- Upload binary image dataPOST /v1/images
PUT /v1/images/<IMAGE_ID>
PUT /v2/images/<IMAGE_ID>/file
copy_from
- Copy binary image data from URLPOST /v1/images
PUT /v1/images/<IMAGE_ID>
add_image
- Create an image entityPOST /v1/images
POST /v2/images
modify_image
- Update an image entityPUT /v1/images/<IMAGE_ID>
PUT /v2/images/<IMAGE_ID>
publicize_image
- Create or update public imagesPOST /v1/images
with attributeis_public
=true
PUT /v1/images/<IMAGE_ID>
with attributeis_public
=true
POST /v2/images
with attributevisibility
=public
PUT /v2/images/<IMAGE_ID>
with attributevisibility
=public
communitize_image
- Create or update community imagesPOST /v2/images
with attributevisibility
=community
PUT /v2/images/<IMAGE_ID>
with attributevisibility
=community
delete_image
- Delete an image entity and associated binary dataDELETE /v1/images/<IMAGE_ID>
DELETE /v2/images/<IMAGE_ID>
add_member
- Add a membership to the member repo of an imagePOST /v2/images/<IMAGE_ID>/members
get_members
- List the members of an imageGET /v1/images/<IMAGE_ID>/members
GET /v2/images/<IMAGE_ID>/members
delete_member
- Delete a membership of an imageDELETE /v1/images/<IMAGE_ID>/members/<MEMBER_ID>
DELETE /v2/images/<IMAGE_ID>/members/<MEMBER_ID>
modify_member
- Create or update the membership of an imagePUT /v1/images/<IMAGE_ID>/members/<MEMBER_ID>
PUT /v1/images/<IMAGE_ID>/members
POST /v2/images/<IMAGE_ID>/members
PUT /v2/images/<IMAGE_ID>/members/<MEMBER_ID>
manage_image_cache
- Allowed to use the image cache management API
To limit an action to a particular role or roles, you list the roles like so :
{
"delete_image": ["role:admin", "role:superuser"]
}
The above would add a rule that only allowed users that had roles of either "admin" or "superuser" to delete an image.
Writing Rules
Role checks are going to continue to work exactly as they already do.
If the role defined in the check is one that the user holds, then that
will pass, e.g., role:admin
.
To write a generic rule, you need to know that there are three values
provided by Glance that can be used in a rule on the left side of the
colon (:
). Those values are the current user's credentials
in the form of:
- role
- tenant
- owner
The left side of the colon can also contain any value that Python can understand, e.g.,:
True
False
"a string"
- &c.
Using tenant
and owner
will only work with
images. Consider the following rule:
tenant:%(owner)s
This will use the tenant
value of the currently
authenticated user. It will also use owner
from the image
it is acting upon. If those two values are equivalent the check will
pass. All attributes on an image (as well as extra image properties) are
available for use on the right side of the colon. The most useful are
the following:
owner
protected
is_public
Therefore, you could construct a set of rules like the following:
{
"not_protected": "False:%(protected)s",
"is_owner": "tenant:%(owner)s",
"is_owner_or_admin": "rule:is_owner or role:admin",
"not_protected_and_is_owner": "rule:not_protected and rule:is_owner",
"get_image": "rule:is_owner_or_admin",
"delete_image": "rule:not_protected_and_is_owner",
"add_member": "rule:not_protected_and_is_owner"
}
Examples
Example 1. (The default policy configuration)
{
"default": ""
}
Note that an empty JSON list means that all methods of the Glance API are callable by anyone.
Example 2. Disallow modification calls to non-admins
{
"default": "",
"add_image": "role:admin",
"modify_image": "role:admin",
"delete_image": "role:admin"
}