Comment 66 for bug 2004555

Hi Nick,

I've been looking at possible mitigations without code changes and there is a way with configuration changes and policy changes. Steps would be:

1- Configure cinder and nova to use the "service_user" and to send the token ("send_service_user_token") [1]
2- Get the service uuid for the cinder and nova service users
3- If using Cinder as a glance backend, get the uuid for the "cinder_store_user_name" from the glance configuration and ensure that the user has the service role.
4- Write the /etc/cinder/policy.yaml file

Assuming that the user names for each of the services match the service name we can get their uuid with:
  $ openstack user show nova -f value -c id
  $ openstack user show cinder -f value -c id
  $ openstack user show glance -f value -c id

The policy I would recommend writing is:
  "is_nova_service": "service_user_id:<nova_service_uuid> or user_id:<nova_service_uuid>"
  "is_cinder_service": "service_user_id:<cinder_service_uuid> or user_id:<cinder_service_uuid>"
  "is_glance_service": "service_user_id:<cinder_store_user_name_uuid> or user_id:<cinder_store_user_name_uuid>"
  "is_service": "rule:is_nova_service or rule:is_glance_service or rule:is_cinder_service"
  "volume:attachment_delete": "rule:admin_api or (rule:admin_or_owner and rule:is_service) or role:service"

A much smaller policy is possible, but I like the one above and is the one that have tested. This one probably works as well, assuming everything has been configured as mentioned above:
  "volume:attachment_delete": "rule:admin_api or (rule:admin_or_owner and (service_user_id:<nova_service_uuid> or service_user_id:<cinder_service_uuid> or role:service))"

These policies don't prevent:
- Admins shooting themselves in the foot
- Unintentional issues like the one originally reported in this case.

They should prevent the user induced vulnerability.

Cheers,
Gorka.

[1]: https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html