Comment 73 for bug 2004555

> I'm afraid that if we try to figure out the source of the request
> ourselves somehow, we'll be subject to some kind of request forgery
> exploit. I think sticking with the service_token is the safest course
> of action. The upside is that all the concerned services use the
> keystone middleware that supports send_service_token, so other than
> configuring each service correctly, there's no software upgrade or
> anything involved.

Yeah sorry, I was responding to the idea that we would have to: 1) accommodate the scenario where the deployer has *not* configured send_service_user_token and 2) accommodate it *without* requiring any config change by the deployer. If we can't require a config change, then I was saying maybe we could check for the "service" role (plain role).

I would much rather be able to use the service_token and require deployers to have send_service_user_token configured in order to be protected from this vulnerability. But it was not clear to me how far we can go with what action we can require from deployers when they install the update containing the exploit mitigation. If we require:

  [service_user]
  send_service_user_token = True

what will we do if it's False (the default)? Make nova services exit if it's not set to True with an error logged to say it's now required? If we don't do anything, when nova calls the detach API it would create a loop, as Dan mentioned in an earlier comment.

> I agree with you completely here, and for the reasons you state, we
> won't be able to provide a script to do this automatically. We'll
> have to provide clear documentation of how to configure this correctly.
> But the plus side is that while the send_user_token stuff may not be
> configured at a site, the must be some kind of service user configured
> for each service (at least I think so?), and we can refer to the config
> options by name in explaining what to do to configure send_user_token
> and make the policy file changes.

I would expect that even if a deployment has left [service_user]send_service_user_token = False, they would have some form of service user set up in keystone. But I am not 100% sure whether it's possible to run openstack without any dedicated service users today.