IMDSv2 lead here! Overall the IMDS is a pretty massive security win ... it means that software and scripts can use short-lived ephemeral credentials that are ti

IMDSv2 lead here! Overall the IMDS is a pretty massive security win ... it means that software and scripts can use short-lived ephemeral credentials that are tied to an instance role very easily. That rules out the kinds of credential leakage issues mentioned in this article, but also filesystem traversal issues and so on that have been common in software historically. That's the big why. It's a HTTP interface so that the most software can benefit from that, whether it's a shell script using curl or something written in Java, Scala, Python, Node.js, Rust, whatever ... pretty much everything can make HTTP requests. Of course over time that HTTP interface became a target itself and when applications have SSRF issues, badness could ensue. IMDSv2 limits the reachability in four ways to protect against SSRF. 1. The IMDS can be entirely turned off if you prefer. 2. Access requires a PUT request, our analysis showed that SSRFs that grant the ability to PUT are very rare. Most SSRF issues only grant GET because they are a URL or header escaping issue that don't give up control of the method. 3. Requests with X-Forwarded-For are denied, so if it's a misconfigured open proxy or WAF that adds this header, you get protection. 4. The request has to come from the local box because we set the IP TTL to "1" which means it isn't routable off-box. This protects against misconfigured NATs and routers.