Comment 2 for bug 1841933

Nova API's metadata service can identify the requesting instance with several possible identifiers:
- OpenStack/Nova instance id, coded into X-Instance-ID header within the metadata HTTP request.
* This is what vanilla OpenStack deployments use *
This bug is irrelevant in this case.

- Use the combination of X-Metadata-Provider and X-Forwarded-For to query Neutron, and conclude the instance id. This is where the bug above is relevant.
A metadata provider is a router is set by an L3 object (e.g router) which is connected to the network, where the requesting instance is connected.
Within a cloud which has overlapping subnets, the combination of a router, which cannot be connected to two subnets that overlap (indeed mostly private IPs and link locals), and the instance IP - which is stored in X-Forwarded-For header, should be unique and identify the requesting instance.
However, if Neutron, due to a bug, responds with an empty list of subnets, Nova metadata service doesn't stop but still queries for ports of instances with the requesting instance's IP - of _any_network_.
So if the requesting instance of tenant A has IP X, it might receive the metadata of another instance, of tenant B, which also uses the same IP.
In the case above, tenant A could acquire SSH keys of tenant B - this is not the classic attacker case but more of a leak of confidential information from one tenant to the other.