Comment 70 for bug 2004555

> I just realized that the cinder-patch needs improvements, because the presence of a service token in the request (and by extension the service roles in the context) depends on the deployment options, and some deployments may not have the "send_service_user_token" configured.

Hm. I wonder if we could instead only check whether the user requesting has the "service" role (if "service" in RequestContext.roles) or is a member of the "service" project? And leave the service_token part out of it.

Technically a deployment could give any project or role to their service users (and omit any) ... so I'm not sure whether it's reasonable to assume any of the project names or role names or user names.

I just can't think of another real way to verify the identity of the caller other than openstack credentials. There has to be a source of truth for verifying the identity of any caller.

> I'll give the patch another thought and add code for that scenario.
My initial idea is to check current actions on the instance to determine if the request is coming from the service or not, though I'm not familiar with all the nova actions that can trigger a cinder detach action.

I'm not sure how nova actions could be a reliable way to know if nova called the detach API. There isn't a unique identifier sent to cinder that cinder could use to validate a request matches a server action. Each server action contains the request_id that performed it, but that wouldn't get sent to cinder unless it's sent as the global_request_id. Nova will send the request_id as the global_request_id only if there is not a global_request_id already in the RequestContext. So that wouldn't work if anyone sent a global_request_id when they called nova.

Other than that, you could only try to correlate the request based on server action timestamp unless I'm missing something.