Policy Personas and Permissions

Beginning with the Xena release, the Block Storage service API v3 takes advantage of the default authentication and authorization apparatus supplied by the Keystone project to give operators a rich set of default policies to control how users interact with the Block Storage service API.

This document describes Cinder’s part in an effort across OpenStack services to provide a consistent and useful default RBAC configuration. (This effort is referred to as “secure RBAC” for short.)

Note

The secure RBAC effort not only spans OpenStack services, it is also taking place over several OpenStack development cycles. Thus it’s important to make sure that you are looking at the version of this document that is applicable to the OpenStack release you have deployed.

This document applies to the Yoga release.

Additionally, keep in mind that different projects are implementing secure RBAC on different schedules. This document applies only to Cinder. To get an idea of the full scope of this effort, consult the Consistent and Secure Default RBAC community goal document.

Vocabulary Note

We need to clarify some terms we’ll be using below.

Project

This is a grouping of users into a unit that can own cloud resources. (This is what used to be called a “tenant”, but you should never call it that.) Users, projects, and their associations are created in Keystone.

Service

This is an OpenStack component that users interact with through an API it provides. For example, “Cinder” is the OpenStack code name for the service that provides the Block Storage API version 3. Cinder is also known as the OpenStack Block Storage service.

The point of making this distinction is that there’s another use of the term ‘project’ that is relevant to the discussion, but that we’re not going to use. Each OpenStack service is produced and maintained by a “project team”. We will not be using the term ‘project’ in that sense in this document. We’ll always use the term ‘service’. (If you are new to OpenStack, this won’t be a problem. But if you’re discussing this content with someone who’s been around OpenStack for a while, you’ll want to be clear about this so that you’re not talking past each other.)

The Cinder Personas

This is easiest to explain if we introduce the three “personas” Cinder recognizes in the Xena and Yoga releases. In the list below, a “system” refers to the deployed system (that is, Cinder and all its services), and a “project” refers to a container or namespace for resources.

• In order to consume resources, a user must be assigned to a project by being given a role (for example, ‘member’) in that project. That’s done in Keystone; it’s not a Cinder concern.

  See Default Roles in the Keystone documentation for more information.

The Cinder Personas in Xena and Yoga

who	what
project-reader	Has access to the API for read-only requests that affect only project-specific resources (that is, cannot create, update, or delete resources within a project)
project-member	A normal user in a project.
system-admin	Has the highest level of authorization on the system and can perform any action in Cinder. In most deployments, only the operator, deployer, or other highly trusted person will be assigned this persona. This is a Cinder super-user who can do everything, both with respect to the Cinder system and all individual projects. Note that if you assign the ‘admin’ role to a user, that user can affect the entire Cinder system, not just the project that person is a member of. Please keep this in mind as you assign roles to users in the Identity service.

Note

The Keystone project provides the ability to describe additional personas, but Cinder does not recognize them in Yoga. In particular:

• Cinder does not recognize the domain scope at all. So even if you successfully request a “domain-scoped” token from the Identity service, you won’t be able to use it with Cinder. Instead, request a “project-scoped” token for the particular project in your domain that you want to act upon.

• Cinder does not recognize a “system-member” persona, that is, a user with the member role on a system. Likewise, cinder does not recognize a “system-reader” persona, that is, a user with the reader role on a system.

  Further, while the Cinder “system-admin” persona is implemented in Yoga, it is not implemented by using scope.

More information about roles and scope is available in the Keystone Administrator Guides.

Note

Privacy Expectations

Cinder’s model of resources (volumes, backups, snapshots, etc.) is that they are owned by the project. Thus, they are shared by all users who have a role assignment on that project, no matter what persona that user has been assigned.

For example, if Alice and Bob are in Project P, and Alice has persona project-member while Bob has persona project-reader, if Alice creates volume V in Project P, Bob can see volume V in the volume-list response, and Bob can read all the volume metadata on volume V that Alice can read–even volume metadata that Alice may have added to the volume. The key point here is that even though Alice created volume V, it’s not her volume. The volume is “owned” by Project P and is available to all users who have authorization on that project via role assignments in keystone. What a user can do with volume V depends on whether that user has an admin, member, or reader role in project P.

With respect to Project P, the personas with system scope (system-admin and system-reader) have access to the project in the sense that a cinder system-admin can do anything in Project P that the project-admin can do plus some additional powers. A cinder system-reader has read-only access to everything in Project P that the system-admin can access.

The above describe the default policy configuration for Cinder. It is possible to modify policies to obtain different behavior, but that is beyond the scope of this document.

Implementation Schedule

For reasons that will become clear in this section, the secure RBAC effort is being implemented in Cinder in two phases. In Xena and Yoga, there are three personas.

The 3 Xena/Yoga Personas

who	Keystone technical info
project-reader	reader role on a project, resulting in project-scope
project-member	member role on a project, resulting in project-scope
system-admin	admin role on a project, but recognized by Cinder as having permission to act on the cinder system

Note that you cannot create a project-admin persona on your own simply by assigning the admin role to a user. Such assignment results in that user becoming a system-admin.

In the Zed release, we plan to implement more Cinder personas that the default policy configuration will recognize. During the development of this OpenStack wide effort, however, some complexities were discovered that have affected exactly what this set of personas and their capabilities will be. Please consult the Zed version of this document (or the ‘latest’ version, if at the time you are reading this, Zed is still under development) for more information.

Cinder Permissions Matrix

Now that you know who the personas are, here’s what they can do with respect to the policies that are recognized by Cinder.

Attachments (Microversion 3.27)

functionality	API call	policy name	project-reader	project-member	system-admin
Create attachment	POST /attachments	volume:attachment_create	no	yes	yes
Update attachment	PUT  /attachments/{attachment_id}	volume:attachment_update	no	yes	yes
Delete attachment	DELETE  /attachments/{attachment_id}	volume:attachment_delete	no	yes	yes
Mark a volume attachment process as completed (in-use)	Microversion 3.44 POST  /attachments/{attachment_id}/action (os-complete)	volume:attachment_complete	no	yes	yes
Allow multiattach of bootable volumes	This is a secondary check on POST  /attachments which is governed by another policy	volume:multiattach_bootable_volume	no	yes	yes

User Messages (Microversion 3.3)

functionality	API call	policy name	project-reader	project-member	system-admin
List messages	GET  /messages	message:get_all	yes	yes	yes
Show message	GET  /messages/{message_id}	message:get	yes	yes	yes
Delete message	DELETE  /messages/{message_id}	message:delete	no	yes	yes

Clusters (Microversion 3.7)

functionality	API call	policy name	project-reader	project-member	system-admin
List clusters	GET  /clusters GET  /clusters/detail	clusters:get_all	no	no	yes
Show cluster	GET  /clusters/{cluster_id}	clusters:get	no	no	yes
Update cluster	PUT  /clusters/{cluster_id}	clusters:update	no	no	yes

Workers (Microversion 3.24)

functionality	API call	policy name	project-reader	project-member	system-admin
Clean up workers	POST  /workers/cleanup	workers:cleanup	no	no	yes

Snapshots

functionality	API call	policy name	project-reader	project-member	system-admin
List snapshots	GET  /snapshots GET  /snapshots/detail	volume:get_all_snapshots	yes	yes	yes
List or show snapshots with extended attributes	GET  /snapshots/{snapshot_id} GET  /snapshots/detail	volume_extension:extended_snapshot_attributes	yes	yes	yes
Create snapshot	POST  /snapshots	volume:create_snapshot	no	yes	yes
Show snapshot	GET  /snapshots/{snapshot_id}	volume:get_snapshot	yes	yes	yes
Update snapshot	PUT  /snapshots/{snapshot_id}	volume:update_snapshot	no	yes	yes
Delete snapshot	DELETE  /snapshots/{snapshot_id}	volume:delete_snapshot	no	yes	yes
Reset status of a snapshot.	POST  /snapshots/{snapshot_id}/action (os-reset_status)	volume_extension:snapshot_admin_actions:reset_status	no	no	yes
Update status (and optionally progress) of snapshot	POST  /snapshots/{snapshot_id}/action (os-update_snapshot_status)	snapshot_extension:snapshot_actions:update_snapshot_status	no	yes	yes
Force delete a snapshot	POST  /snapshots/{snapshot_id}/action (os-force_delete)	volume_extension:snapshot_admin_actions:force_delete	no	no	yes
List (in detail) of snapshots which are available to manage	GET  /manageable_snapshots GET  /manageable_snapshots/detail	snapshot_extension:list_manageable	no	no	yes
Manage an existing snapshot	POST  /manageable_snapshots	snapshot_extension:snapshot_manage	no	no	yes
Unmanage a snapshot	POST  /snapshots/{snapshot_id}/action (os-unmanage)	snapshot_extension:snapshot_unmanage	no	no	yes

Snapshot Metadata

functionality	API call	policy name	project-reader	project-member	system-admin
Show snapshot’s metadata or one specified metadata with a given key	GET  /snapshots/{snapshot_id}/metadata GET  /snapshots/{snapshot_id}/metadata/{key}	volume:get_snapshot_metadata	yes	yes	yes
Update snapshot’s metadata or one specified metadata with a given key	PUT  /snapshots/{snapshot_id}/metadata PUT  /snapshots/{snapshot_id}/metadata/{key}	volume:update_snapshot_metadata	no	yes	yes
Delete snapshot’s specified metadata with a given key	DELETE  /snapshots/{snapshot_id}/metadata/{key}	volume:delete_snapshot_metadata	no	yes	yes

Backups

functionality	API call	policy name	project-reader	project-member	system-admin
List backups	GET  /backups GET  /backups/detail	backup:get_all	yes	yes	yes
Include project attributes in the list backups, show backup responses	Microversion 3.18 Adds os-backup-project-attr:project_id to the following responses: GET  /backups/detail GET  /backups/{backup_id} The ability to make these API calls is governed by other policies.	backup:backup_project_attribute	no	no	yes
Create backup	POST  /backups	backup:create	no	yes	yes
Show backup	GET  /backups/{backup_id}	backup:get	yes	yes	yes
Update backup	Microversion 3.9 PUT  /backups/{backup_id}	backup:update	no	yes	yes
Delete backup	DELETE  /backups/{backup_id}	backup:delete	no	yes	yes
Restore backup	POST  /backups/{backup_id}/restore	backup:restore	no	yes	yes
Import backup	POST  /backups/{backup_id}/import_record	backup:backup-import	no	no	yes
Export backup	POST  /backups/{backup_id}/export_record	backup:export-import	no	no	yes
Reset status of a backup	POST  /backups/{backup_id}/action (os-reset_status)	volume_extension:backup_admin_actions:reset_status	no	no	yes
Force delete a backup	POST  /backups/{backup_id}/action (os-force_delete)	volume_extension:backup_admin_actions:force_delete	no	no	yes

Groups (Microversion 3.13)

functionality	API call	policy name	project-reader	project-member	system-admin
List groups	GET  /groups GET  /groups/detail	group:get_all	yes	yes	yes
Create group, create group from src	POST  /groups Microversion 3.14: POST  /groups/action (create-from-src)	group:create	no	yes	yes
Show group	GET  /groups/{group_id}	group:get	yes	yes	yes
Update group	PUT  /groups/{group_id}	group:update	no	yes	yes
Include project attributes in the list groups, show group responses	Microversion 3.58 Adds project_id to the following responses: GET  /groups/detail GET  /groups/{group_id} The ability to make these API calls is governed by other policies.	group:group_project_attribute	no	no	yes

Group Types (Microversion 3.11)

functionality	API call	policy name	project-reader	project-member	system-admin
DEPRECATED Create, update or delete a group type	(NOTE: Yoga policies split POST, PUT, DELETE) POST /group_types/ PUT /group_types/{group_type_id} DELETE /group_types/{group_type_id}	group:group_types_manage	no	no	yes
Create a group type	POST /group_types/	group:group_types:create	no	no	yes
Update a group type	PUT /group_types/{group_type_id}	group:group_types:update	no	no	yes
Delete a group type	DELETE /group_types/{group_type_id}	group:group_types:delete	no	no	yes
Show group type with type specs attributes	Adds group_specs to the following responses: GET  /group_types GET  /group_types/default GET  /group_types/{group_type_id} These calls are not governed by a policy.	group:access_group_types_specs	no	no	yes
DEPRECATED Create, show, update and delete group type spec	(NOTE: Yoga policies split GET, POST, PUT, DELETE) GET /group_types/{group_type_id}/group_specs GET /group_types/{group_type_id}/group_specs/{g_spec_id} POST /group_types/{group_type_id}/group_specs PUT /group_types/{group_type_id}/group_specs/{g_spec_id} DELETE  /group_types/{group_type_id}/group_specs/{g_spec_id}	group:group_types_specs	no	no	yes
Create group type spec	POST /group_types/{group_type_id}/group_specs	group:group_types_specs:create	no	no	yes
List group type specs	GET /group_types/{group_type_id}/group_specs	group:group_types_specs:get_all	no	no	yes
Show detail for a group type spec	GET /group_types/{group_type_id}/group_specs/{g_spec_id}	group:group_types_specs:get	no	no	yes
Update group type spec	PUT /group_types/{group_type_id}/group_specs/{g_spec_id}	group:group_types_specs:update	no	no	yes
Delete group type spec	DELETE /group_types/{group_type_id}/group_specs/{g_spec_id}	group:group_types_specs:delete	no	no	yes

Group Snapshots (Microversion 3.14)

functionality	API call	policy name	project-reader	project-member	system-admin
List group snapshots	GET  /group_snapshots GET  /group_snapshots/detail	group:get_all_group_snapshots	yes	yes	yes
Create group snapshot	POST  /group_snapshots	group:create_group_snapshot	no	yes	yes
Show group snapshot	GET  /group_snapshots/{group_snapshot_id}	group:get_group_snapshot	yes	yes	yes
Delete group snapshot	DELETE  /group_snapshots/{group_snapshot_id}	group:delete_group_snapshot	no	yes	yes
Update group snapshot	PUT  /group_snapshots/{group_snapshot_id} Note: even though the policy is defined, this call is not implemented in the Block Storage API.	group:update_group_snapshot	no	yes	yes
Reset status of group snapshot	Microversion 3.19 POST  /group_snapshots/{group_snapshot_id}/action (reset_status)	group:reset_group_snapshot_status	no	no	yes
Include project attributes in the list group snapshots, show group snapshot responses	Microversion 3.58 Adds project_id to the following responses: GET  /group_snapshots/detail GET  /group_snapshots/{group_snapshot_id} The ability to make these API calls is governed by other policies.	group:group_snapshot_project_attribute	no	no	yes

Group Actions

functionality	API call	policy name	project-reader	project-member	system-admin
Delete group	POST  /groups/{group_id}/action (delete)	group:delete	no	yes	yes
Reset status of group	Microversion 3.20 POST  /groups/{group_id}/action (reset_status)	group:reset_status	no	no	yes
Enable replication	Microversion 3.38 POST  /groups/{group_id}/action (enable_replication)	group:enable_replication	no	yes	yes
Disable replication	Microversion 3.38 POST  /groups/{group_id}/action (disable_replication)	group:disable_replication	no	yes	yes
Fail over replication	Microversion 3.38 POST  /groups/{group_id}/action (failover_replication)	group:failover_replication	no	yes	yes
List failover replication	Microversion 3.38 POST  /groups/{group_id}/action (list_replication_targets)	group:list_replication_targets	no	yes	yes

QOS specs

functionality	API call	policy name	project-reader	project-member	system-admin
List qos specs or list all associations	GET  /qos-specs GET  /qos-specs/{qos_id}/associations	volume_extension:qos_specs_manage:get_all	no	no	yes
Show qos specs	GET  /qos-specs/{qos_id}	volume_extension:qos_specs_manage:get	no	no	yes
Create qos specs	POST  /qos-specs	volume_extension:qos_specs_manage:create	no	no	yes
Update qos specs: update key/values in the qos-spec or update the volume-types associated with the qos-spec	PUT  /qos-specs/{qos_id} GET  /qos-specs/{qos_id}/associate?vol_type_id={volume_id} GET  /qos-specs/{qos_id}/disassociate?vol_type_id={volume_id} GET  /qos-specs/{qos_id}/disassociate_all (yes, these GETs are really updates)	volume_extension:qos_specs_manage:update	no	no	yes
Delete a qos-spec, or remove a list of keys from the qos-spec	DELETE  /qos-specs/{qos_id} PUT  /qos-specs/{qos_id}/delete_keys	volume_extension:qos_specs_manage:delete	no	no	yes

Quotas

functionality	API call	policy name	project-reader	project-member	system-admin
DEPRECATED Show or update project quota class	(NOTE: Yoga policies split GET and PUT) GET  /os-quota-class-sets/{project_id} PUT  /os-quota-class-sets/{project_id}	volume_extension:quota_classes	no	no	yes
Show project quota class	GET  /os-quota-class-sets/{project_id}	volume_extension:quota_classes:get	no	no	yes
Update project quota class	PUT  /os-quota-class-sets/{project_id}	volume_extension:quota_classes:update	no	no	yes
Show project quota (including usage and default)	GET  /os-quota-sets/{project_id} GET  /os-quota-sets/{project_id}/default GET  /os-quota-sets/{project_id}?usage=True	volume_extension:quotas:show	yes	yes	yes
Update project quota	PUT  /os-quota-sets/{project_id}	volume_extension:quotas:update	no	no	yes
Delete project quota	DELETE  /os-quota-sets/{project_id}	volume_extension:quotas:delete	no	no	yes

Capabilities

functionality	API call	policy name	project-reader	project-member	system-admin
Show backend capabilities	GET  /capabilities/{host_name}	volume_extension:capabilities	no	no	yes

Services

functionality	API call	policy name	project-reader	project-member	system-admin
List all services	GET  /os-services	volume_extension:services:index	no	no	yes
Update service	PUT  /os-services/enable PUT  /os-services/disable PUT  /os-services/disable-log-reason PUT  /os-services/freeze PUT  /os-services/thaw PUT  /os-services/failover_host PUT  /os-services/failover (microversion 3.26) PUT  /os-services/set-log PUT  /os-services/get-log	volume_extension:services:update	no	no	yes
Freeze a backend host. Secondary check; must also satisfy volume_extension:services:update to make this call.	PUT  /os-services/freeze	volume:freeze_host	no	no	yes
Thaw a backend host. Secondary check; must also satisfy volume_extension:services:update to make this call.	PUT  /os-services/thaw	volume:thaw_host	no	no	yes
Failover a backend host. Secondary check; must also satisfy volume_extension:services:update to make this call.	PUT  /os-services/failover_host PUT  /os-services/failover (microversion 3.26)	volume:failover_host	no	no	yes
List all backend pools	GET  /scheduler-stats/get_pools	scheduler_extension:scheduler_stats:get_pools	no	no	yes
List, update or show hosts for a project (NOTE: will be deprecated in Zed and new policies introduced for GETs and PUT)	GET  /os-hosts PUT  /os-hosts/{host_name} GET  /os-hosts/{host_id}	volume_extension:hosts	no	no	yes
Show limits with used limit attributes	GET  /limits	limits_extension:used_limits	yes	yes	yes
List (in detail) of volumes which are available to manage	GET  /manageable_volumes GET  /manageable_volumes/detail	volume_extension:list_manageable	no	no	yes
Manage existing volumes	POST  /manageable_volumes	volume_extension:volume_manage	no	no	yes
Unmanage a volume	POST  /volumes/{volume_id}/action (os-unmanage)	volume_extension:volume_unmanage	no	no	yes

Volume Types

functionality	API call	policy name	project-reader	project-member	system-admin
DEPRECATED Create, update and delete volume type (Yoga policies for create/update/delete)	POST  /types PUT  /types/{type_id} DELETE  /types	volume_extension:types_manage	no	no	yes
Create a volume type	POST  /types	volume_extension:type_create	no	no	yes
Update a volume type	PUT  /types/{type_id}	volume_extension:type_update	no	no	yes
Delete a volume type	DELETE  /types/{type_id}	volume_extension:type_delete	no	no	yes
Show a specific volume type	GET  /types/{type_id}	volume_extension:type_get	yes	yes	yes
List volume types	GET  /types	volume_extension:type_get_all	yes	yes	yes
DEPRECATED Base policy for all volume type encryption type operations (NOTE: can’t use this anymore, because it gives GET and POST same permissions)	Convenience default policy for the situation where you don’t want to configure all the volume_type_encryption policies separately	volume_extension:volume_type_encryption
Create volume type encryption	POST  /types/{type_id}/encryption	volume_extension:volume_type_encryption:create	no	no	yes
Show a volume type’s encryption type, show an encryption specs item	GET  /types/{type_id}/encryption GET  /types/{type_id}/encryption/{key}	volume_extension:volume_type_encryption:get	no	no	yes
Update volume type encryption	PUT  /types/{type_id}/encryption/{encryption_id}	volume_extension:volume_type_encryption:update	no	no	yes
Delete volume type encryption	DELETE  /types/{type_id}/encryption/{encryption_id}	volume_extension:volume_type_encryption:delete	no	no	yes
List or show volume type with extra specs attribute	Adds extra_specs to the following responses: GET  /types/{type_id} GET  /types The ability to make these API calls is governed by other policies.	volume_extension:access_types_extra_specs	yes	yes	yes
List or show volume type with access type qos specs id attribute	Adds qos_specs_id to the following responses: GET  /types/{type_id} GET  /types The ability to make these API calls is governed by other policies.	volume_extension:access_types_qos_specs_id	no	no	yes
Show whether a volume type is public in the type response	Adds os-volume-type-access:is_public to the following responses: GET  /types GET  /types/{type_id} POST  /types The ability to make these API calls is governed by other policies.	volume_extension:volume_type_access	no	yes	yes
List private volume type access detail, that is, list the projects that have access to this type (was formerly controlled by volume_extension:volume_type_access)	GET  /types/{type_id}/os-volume-type-access	volume_extension:volume_type_access:get_all_for_type	no	no	yes
Add volume type access for project	POST  /types/{type_id}/action (addProjectAccess)	volume_extension:volume_type_access:addProjectAccess	no	no	yes
Remove volume type access for project	POST  /types/{type_id}/action (removeProjectAccess)	volume_extension:volume_type_access:removeProjectAccess	no	no	yes

Volume Actions

functionality	API call	policy name	project-reader	project-member	system-admin
Extend a volume	POST  /volumes/{volume_id}/action (os-extend)	volume:extend	no	yes	yes
Extend an attached volume	Microversion 3.42 POST  /volumes/{volume_id}/action (os-extend)	volume:extend_attached_volume	no	yes	yes
Revert a volume to a snapshot	Microversion 3.40 POST  /volumes/{volume_id}/action (revert)	volume:revert_to_snapshot	no	yes	yes
Reset status of a volume	POST  /volumes/{volume_id}/action (os-reset_status)	volume_extension:volume_admin_actions:reset_status	no	no	yes
Retype a volume	POST  /volumes/{volume_id}/action (os-retype)	volume:retype	no	yes	yes
Update a volume’s readonly flag	POST  /volumes/{volume_id}/action (os-update_readonly_flag)	volume:update_readonly_flag	no	yes	yes
Force delete a volume	POST  /volumes/{volume_id}/action (os-force_delete)	volume_extension:volume_admin_actions:force_delete	no	no	yes
Upload a volume to image with public visibility	POST  /volumes/{volume_id}/action (os-volume_upload_image)	volume_extension:volume_actions:upload_public	no	no	yes
Upload a volume to image	POST  /volumes/{volume_id}/action (os-volume_upload_image)	volume_extension:volume_actions:upload_image	no	yes	yes
Force detach a volume.	POST  /volumes/{volume_id}/action (os-force_detach)	volume_extension:volume_admin_actions:force_detach	no	no	yes
Migrate a volume to a specified host	POST  /volumes/{volume_id}/action (os-migrate_volume)	volume_extension:volume_admin_actions:migrate_volume	no	no	yes
Complete a volume migration	POST  /volumes/{volume_id}/action (os-migrate_volume_completion)	volume_extension:volume_admin_actions:migrate_volume_completion	no	no	yes
Initialize volume attachment	POST  /volumes/{volume_id}/action (os-initialize_connection)	volume_extension:volume_actions:initialize_connection	no	yes	yes
Terminate volume attachment	POST  /volumes/{volume_id}/action (os-terminate_connection)	volume_extension:volume_actions:terminate_connection	no	yes	yes
Roll back volume status to ‘in-use’	POST  /volumes/{volume_id}/action (os-roll_detaching)	volume_extension:volume_actions:roll_detaching	no	yes	yes
Mark volume as reserved	POST  /volumes/{volume_id}/action (os-reserve)	volume_extension:volume_actions:reserve	no	yes	yes
Unmark volume as reserved	POST  /volumes/{volume_id}/action (os-unreserve)	volume_extension:volume_actions:unreserve	no	yes	yes
Begin detach volumes	POST  /volumes/{volume_id}/action (os-begin_detaching)	volume_extension:volume_actions:begin_detaching	no	yes	yes
Add attachment metadata	POST  /volumes/{volume_id}/action (os-attach)	volume_extension:volume_actions:attach	no	yes	yes
Clear attachment metadata	POST  /volumes/{volume_id}/action (os-detach)	volume_extension:volume_actions:detach	no	yes	yes
Reimage a volume in available or error status	POST  /volumes/{volume_id}/action (os-reimage)	volume:reimage	no	yes	yes
Reimage a volume in reserved status	POST  /volumes/{volume_id}/action (os-reimage)	volume:reimage_reserved	no	yes	yes

Volume Transfers

functionality	API call	policy name	project-reader	project-member	system-admin
List volume transfer	GET  /os-volume-transfer GET  /os-volume-transfer/detail GET  /volume-transfers GET  /volume-transfers/detail	volume:get_all_transfers	yes	yes	yes
Create a volume transfer	POST  /os-volume-transfer POST  /volume-transfers	volume:create_transfer	no	yes	yes
Show one specified volume transfer	GET  /os-volume-transfer/{transfer_id} GET  /volume-transfers/{transfer_id}	volume:get_transfer	yes	yes	yes
Accept a volume transfer	POST  /os-volume-transfer/{transfer_id}/accept POST  /volume-transfers/{transfer_id}/accept	volume:accept_transfer	no	yes	yes
Delete volume transfer	DELETE  /os-volume-transfer/{transfer_id} DELETE  /volume-transfers/{transfer_id}	volume:delete_transfer	no	yes	yes

Volume Metadata

functionality	API call	policy name	project-reader	project-member	system-admin
Show volume’s metadata or one specified metadata with a given key.	GET  /volumes/{volume_id}/metadata GET  /volumes/{volume_id}/metadata/{key} POST /volumes/{volume_id}/action (os-show_image_metadata)	volume:get_volume_metadata	yes	yes	yes
Create volume metadata	POST  /volumes/{volume_id}/metadata	volume:create_volume_metadata	no	yes	yes
Update volume’s metadata or one specified metadata with a given key	PUT  /volumes/{volume_id}/metadata PUT  /volumes/{volume_id}/metadata/{key}	volume:update_volume_metadata	no	yes	yes
Delete volume’s specified metadata with a given key	DELETE  /volumes/{volume_id}/metadata/{key}	volume:delete_volume_metadata	no	yes	yes
DEPRECATED Volume’s image metadata related operation, create, delete, show and list	(NOTE: Yoga policies split GET and POST) Microversion 3.4 GET  /volumes/detail GET  /volumes/{volume_id} POST  /volumes/{volume_id}/action (os-set_image_metadata) POST  /volumes/{volume_id}/action (os-unset_image_metadata) (NOTE: POST /volumes/{volume_id}/action (os-show_image_metadata) is governed by volume:get_volume_metadata	volume_extension:volume_image_metadata	no	yes	yes
Include volume’s image metadata in volume detail responses	Microversion 3.4 GET  /volumes/detail GET  /volumes/{volume_id} The ability to make these API calls is governed by other policies.	volume_extension:volume_image_metadata:show	yes	yes	yes
Set image metadata for a volume	Microversion 3.4 POST  /volumes/{volume_id}/action (os-set_image_metadata)	volume_extension:volume_image_metadata:set	no	yes	yes
Remove specific image metadata from a volume	Microversion 3.4 POST  /volumes/{volume_id}/action (os-unset_image_metadata)	volume_extension:volume_image_metadata:remove	no	yes	yes
Update volume admin metadata.	This permission is required to complete the following operations: POST  /volumes/{volume_id}/action (os-update_readonly_flag) POST  /volumes/{volume_id}/action (os-attach) The ability to make these API calls is governed by other policies.	volume:update_volume_admin_metadata	no	no	yes

Volume Type Extra-Specs

functionality	API call	policy name	project-reader	project-member	system-admin
List type extra specs	GET  /types/{type_id}/extra_specs	volume_extension:types_extra_specs:index	yes	yes	yes
Create type extra specs	POST  /types/{type_id}/extra_specs	volume_extension:types_extra_specs:create	no	no	yes
Show one specified type extra specs	GET  /types/{type_id}/extra_specs/{extra_spec_key}	volume_extension:types_extra_specs:show	yes	yes	yes
Update type extra specs	PUT  /types/{type_id}/extra_specs/{extra_spec_key}	volume_extension:types_extra_specs:update	no	no	yes
Delete type extra specs	DELETE  /types/{type_id}/extra_specs/{extra_spec_key}	volume_extension:types_extra_specs:delete	no	no	yes
Include extra_specs fields that may reveal sensitive information about the deployment that should not be exposed to end users in various volume-type responses that show extra_specs.	GET  /types GET  /types/{type_id} GET  /types/{type_id}/extra_specs GET  /types/{type_id}/extra_specs/{extra_spec_key} The ability to make these API calls is governed by other policies.	volume_extension:types_extra_specs:read_sensitive	no	no	yes

Volumes

functionality	API call	policy name	project-reader	project-member	system-admin
Create volume	POST  /volumes	volume:create	no	yes	yes
Create volume from image	POST  /volumes	volume:create_from_image	no	yes	yes
Show volume	GET  /volumes/{volume_id}	volume:get	yes	yes	yes
List volumes or get summary of volumes	GET  /volumes GET  /volumes/detail GET  /volumes/summary	volume:get_all	yes	yes	yes
Update volume or update a volume’s bootable status	PUT  /volumes POST  /volumes/{volume_id}/action (os-set_bootable)	volume:update	no	yes	yes
Delete volume	DELETE  /volumes/{volume_id}	volume:delete	no	yes	yes
Force Delete a volume (Microversion 3.23)	DELETE  /volumes/{volume_id}?force=true	volume:force_delete	no	no	yes
List or show volume with host attribute	Adds os-vol-host-attr:host to the following responses: GET  /volumes/{volume_id} GET  /volumes/detail The ability to make these API calls is governed by other policies.	volume_extension:volume_host_attribute	no	no	yes
List or show volume with “tenant attribute” (actually, the project ID)	Adds os-vol-tenant-attr:tenant_id to the following responses: GET  /volumes/{volume_id} GET  /volumes/detail The ability to make these API calls is governed by other policies.	volume_extension:volume_tenant_attribute	yes	yes	yes
List or show volume with migration status attribute	Adds os-vol-mig-status-attr:migstat to the following responses: GET  /volumes/{volume_id} GET  /volumes/detail The ability to make these API calls is governed by other policies.	volume_extension:volume_mig_status_attribute	no	no	yes
Show volume’s encryption metadata	GET  /volumes/{volume_id}/encryption GET  /volumes/{volume_id}/encryption/{encryption_key}	volume_extension:volume_encryption_metadata	yes	yes	yes
Create multiattach capable volume	Indirectly affects the success of these API calls: POST  /volumes POST  /volumes/{volume_id}/action (os-retype) The ability to make these API calls is governed by other policies.	volume:multiattach	no	yes	yes

Default Volume Types (Microversion 3.62)

functionality	API call	policy name	project-reader	project-member	system-admin
Set or update default volume type for a project	PUT  /default-types	volume_extension:default_set_or_update	no	no	yes
Get default type for a project	GET  /default-types/{project-id} (Note: a project-* persona can always determine their effective default-type by making the GET /v3/{project_id}/types/default call, which is governed by the volume_extension:type_get policy.)	volume_extension:default_get	no	no	yes
Get all default types	GET  /default-types/	volume_extension:default_get_all	no	no	yes
Unset default type for a project	DELETE  /default-types/{project-id}	volume_extension:default_unset	no	no	yes