Comment 3 for bug 1916926

I think it is a security issue. We consider being able to test existence of another tenant's image by guessing its UUID to be an information leak, so being able to test for the existence of any other resource by name is worse, IMHO. Customers could easily be encoding sensitive information into resource names, which would make this more than just a leak of infrastructure details. However, since these issues seem to have been baked into the APIs since the beginning, I think we probably shouldn't hold up notification on a heavyweight retooling of the code to fix the underlying issues.

From what I've seen in some brief initial research on these issues, I think cooking up a real fix for this is likely to be non-trivial, especially given where we are in the cycle. I think that the best thing to do here might be to mitigate this problem by changing the policy rules to disable these metadef APIs by default, along with docs and renos about why, how to re-enable them, and what the potential risk is if you do. People using these APIs may decide to continue doing so, but perhaps with different naming conventions to limit exposure. As noted in another related bugs (#1916922) there are other exposures related to this, as well as resource exhaustion issues (#1545702) which would all be things we would want a refactor to address.

After we get those defaults changed and people notified, we can work on either a better long-term fix, or maybe decide that more invasive surgery is needed. AFAICT, these APIs have always been broken in this way, as the policy enforcement points don't pass any target object to the enforcer step(s). Thus it seems like the informational part of this (i.e. an advisory and mitigation steps) are the important part here, as well as warning any new users against building on this functionality without due care.