Comment 10 for bug 1563954

So I thought X-Forwarded-For was a known weakness, all be it a badly documented one.

The configuration option used to say: "Only enable this if you have a sanitizing proxy."
https://github.com/openstack/nova/commit/ca1017988f98a246aa82c16f471791c7ea3eceec

Now somehow that has morphed to "a HTML santizing proxy" which is totally miss-leading:
https://github.com/openstack/nova/blob/master/nova/conf/api.py#L48

We do now have this shared secret checking feature, that the neutron proxy uses:
https://github.com/openstack/nova/blob/2a0fce7a44d4050e112a6b987f24236627632d2c/nova/api/metadata/handler.py#L259
I believe the proxy uses OVS (et al) protections to ensure only the correct VMs can talk to their proxy, then shared secret sent to the load balanced nova metadata api server, or something like that.

@tonyb, I think the issue with your extra option is that with spoofing the source IP, or similar, it doesn't really give us any more security, unless I am missing something? In reality folks really should consider carefully about securing this channel, via some other means they can trust within the context of their network.

What about beefing up the documentation, issuing a security advisory? I think we could also deprecate the proxy feature, telling users to configure a proxy to use the above shared secret system? Does that sound practical?

FWIW, I know many users worry about instance traffic being routed into the control plane, so tend to only deploy with Configuration Drive.

PS
Having access does also allow you to write passwords into the database, blocking the user generating a password, if you time it correctly, if my memory servers me correctly.