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.
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] store_user_ name" from the glance configuration and ensure that the user has the service role. policy. yaml file
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_
4- Write the /etc/cinder/
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: service" : "service_ user_id: <nova_service_ uuid> or user_id: <nova_service_ uuid>" service" : "service_ user_id: <cinder_ service_ uuid> or user_id: <cinder_ service_ uuid>" service" : "service_ user_id: <cinder_ store_user_ name_uuid> or user_id: <cinder_ store_user_ name_uuid> " nova_service or rule:is_ glance_ service or rule:is_ cinder_ service" attachment_ delete" : "rule:admin_api or (rule:admin_ or_owner and rule:is_service) or role:service"
"is_nova_
"is_cinder_
"is_glance_
"is_service": "rule:is_
"volume:
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: 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))"
"volume:
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