What is the instance metadata service (IMDS) and how does IMDSv2 mitigate SSRF?

This is a favorite senior cloud question because it ties together a web vulnerability (SSRF) and a cloud-native attack (credential theft) — and the fix is elegant.

What IMDS does

Every instance can query a link-local address, 169.254.169.254, to read its own metadata: region, instance ID, networking, and — critically — the temporary credentials of the IAM role attached to it. Applications use this so they never need static keys. The problem: the endpoint trusts any request originating from the instance.

Why SSRF is so dangerous here

In a server-side request forgery attack, an attacker coerces the application into making an HTTP request to an attacker-chosen URL. If they point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/..., the server fetches the role's credentials and returns them. The attacker now holds valid, role-scoped cloud credentials — the Capital One breach is the canonical example.

How IMDSv2 closes it

IMDSv1 answered a plain GET, which is exactly what SSRF produces. IMDSv2 is session-oriented:

• The client must first issue a PUT to obtain a short-lived session token, then send that token in a header on every read. Most SSRF primitives can only do simple GETs, so they cannot complete the handshake.
• The default response hop limit (IP TTL) is 1, so the response cannot traverse a forwarding proxy or escape a container's network namespace to reach an external attacker.
• Requests carrying an X-Forwarded-For header are rejected, blocking open-proxy abuse.

Enforce IMDSv2-only at launch (and account-wide via policy), and still scope the instance role tightly so a leak has minimal blast radius.

What interviewers look for

Knowing the metadata IP, that it serves role credentials, the SSRF link, and specifically why the PUT-token plus hop-limit design defeats it.