TL;DR: Cloud VMs and containers reach a metadata service at a link-local address (169.254.169.254 on the major clouds) that returns instance details and, often, temporary credentials for the attached role. Any SSRF on that machine can request them. Modern defences require session tokens obtained with a PUT request and limit hop counts (AWS IMDSv2), or mandatory headers that browsers and naive fetchers do not send (GCP and Azure), so simple GET-based SSRF fails. Defence in depth: enforce IMDSv2, set hop limit 1 for containers that do not need metadata, block metadata from application network paths, and give workloads least-privilege roles so stolen credentials are worth little.
How to approach it
Explain what the metadata service provides and why it is reachable from any process on the host. Then describe how token and header requirements block typical SSRF, where they still fail, and the layered controls.
A strong answer
Legacy metadata (v1-style)
SSRF to 169.254.169.254
simple GET
Role credentials returned
temporary but powerful
Cloud account access
Outcome, unsafe: Credentials stolen
Any SSRF is enough
Token-required metadata
PUT for session token
custom header
Hop limit 1
containers cannot relay
Least-privilege role too
Outcome, safe: Simple SSRF fails
Block metadata from apps that don't need it
Why it is a target. Instances get credentials without storing secrets by asking the local metadata service. That convenience means any code that can make an HTTP request from the instance, including an SSRF in a web application, a vulnerable dependency, or an agent's fetch tool steered by injected text, can obtain the role's credentials and use them from anywhere until they expire.
How modern defences work.
| Cloud mechanism | What it blocks |
|---|---|
AWS IMDSv2: session token from a PUT with a TTL header, presented on each request | SSRF that can only make GET requests or cannot set custom headers |
| IMDSv2 hop limit (TTL on responses) | Requests forwarded from containers or through extra network hops, when set to 1 |
GCP: required Metadata-Flavor: Google header | Fetchers that do not let attackers set headers |
Azure: required Metadata: true header, rejects requests with X-Forwarded-For | Simple proxies and fetchers |
Where they still fail. An SSRF that lets the attacker choose method and headers, or code execution on the host, defeats them. They raise the bar; they do not remove the credential.
Layered controls.
- Enforce IMDSv2 (disable v1) across accounts with organisation policy.
- Set the hop limit to 1 where containers do not need instance credentials; give pods their own workload identity instead.
- Block the metadata address from application egress paths, especially for fetch tools and sandboxes.
- Apply SSRF defences in code: resolve and reject link-local and private addresses.
- Least-privilege instance and workload roles, so the credential reaches little.
- Detect use of instance credentials from outside the instance's expected network or from unusual API patterns.
Agents. A browsing or fetch tool on a cloud host is a ready-made SSRF. Run it in an isolated network segment with no metadata access, behind an egress proxy that rejects non-public addresses.
What interviewers probe next
- "Why do containers complicate this?" Containers on a node can often reach the node's metadata service and inherit the node's role unless hop limits or network policy block it.
- "How would you detect stolen instance credentials?" Alerts when credentials issued to an instance are used from IP addresses outside your environment, which cloud threat-detection services support.
- "Is IMDSv2 enough for an SSRF in a feature that lets users set headers?" No; block the address at the network layer too.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A web app on a cloud VM has a server-side request forgery bug, and the instance has a role with access to production storage buckets.
Start here
Why is the metadata service the main target?
What does the metadata service hand out?
Cloud VMs reach a metadata service at a link-local address (169.254.169.254 on the major clouds) that returns instance details and often temporary credentials for the attached role. Any SSRF on the machine can request them and use them from anywhere.
Carry it forwardSSRF plus metadata can yield role credentials.
Weak answerThinking SSRF only reaches internal web pages.
Constraint changes
How do modern metadata versions help?
What can a typical SSRF bug send?
AWS IMDSv2 requires a session token obtained with a PUT request and limits hop counts; GCP and Azure require mandatory headers that browsers and naive fetchers do not send. Simple GET-based SSRF then fails.
Carry it forwardToken or header requirements block simple SSRF.
Weak answerLeaving IMDSv1 enabled for compatibility.
Constraint changes
What if containers on the host do not need metadata?
Should every container see the node's credentials?
Set the hop limit to 1 so requests from containers cannot reach the service through the extra network hop, or block the metadata address for application processes. Give pods their own workload identity instead of the node's role.
Carry it forwardBlock metadata from workloads that do not need it.
Weak answerLetting pods inherit the node role.
Constraint changes
How do you fix the SSRF itself?
Where does the URL resolve, after redirects?
Route outbound fetches through an allowlist or proxy that resolves names and blocks private, link-local and metadata addresses after redirects. Validating the URL string alone is not enough because of DNS tricks and redirects.
Carry it forwardCheck destinations after resolution and redirects.
Weak answerBlocklisting the string 169.254.169.254.
Constraint changes
What limits damage if credentials are still stolen?
Where are the stolen credentials being used from?
A least-privilege role scoped to what the app needs, not all production buckets, and detection of role credentials used from outside the instance or from unusual locations. Cloud providers offer findings for exactly this.
Carry it forwardScope the role and detect off-instance use.
Weak answerBroad roles on internet-facing instances.
Now defend it
How would you defend this instance?
Fix the SSRF with a resolving egress allowlist; enforce IMDSv2 or required headers; set hop limit 1 and block metadata for workloads that do not need it; use per-workload identities; scope the instance role to what the app needs; and alert on role credentials used outside the instance.
How it's scored
Weak: Knows the address but not the defences.
Hire: Explains credential theft via SSRF and IMDSv2 tokens and hop limits.
Strong Hire: Covers other clouds' header requirements, their limits, container inheritance, least-privilege roles, detection, and agent fetch tools.
Common mistakes
- Leaving IMDSv1 enabled for compatibility.
- Giving node roles broad permissions that pods inherit.
- Relying on application-level URL filters alone.