I've commented on the review for this; but proxies might turn up like so:
VM -> proxy A -> ns-agent -> metadata-agent -> proxy B -> Nova
Or without the ns-agent
VM -> proxy C -> metadata-agent -> proxy D -> Nova
We currently fail open when:
- proxy A is used (the wrong instance data will be returned).
We fail closed when:
- proxy B/C/D are used (too many elements, crash in the code)
Fixing the case for B and D, which I presume this is about will cause C to fail open and possibly allow obtaining metadata for arbitrary instances (including root password). So I believe we need to ensure that we don't open this up inappropriately, and fix the existing security hole [which is mitigated by the fact that you have to be running a proxy A to be attacked, whereas for C it potentially allowing any instance to be queried would be substantially worse.
I've commented on the review for this; but proxies might turn up like so:
VM -> proxy A -> ns-agent -> metadata-agent -> proxy B -> Nova
Or without the ns-agent
VM -> proxy C -> metadata-agent -> proxy D -> Nova
We currently fail open when:
- proxy A is used (the wrong instance data will be returned).
We fail closed when:
- proxy B/C/D are used (too many elements, crash in the code)
Fixing the case for B and D, which I presume this is about will cause C to fail open and possibly allow obtaining metadata for arbitrary instances (including root password). So I believe we need to ensure that we don't open this up inappropriately, and fix the existing security hole [which is mitigated by the fact that you have to be running a proxy A to be attacked, whereas for C it potentially allowing any instance to be queried would be substantially worse.