Cybersecurity glossary
What is a Metadata Service?
Learn what a cloud metadata service is, why workloads query link-local endpoints for identity and config, and how SSRF and open networks turn that convenience into credential theft.
Definition
A metadata service is a provider-operated, typically link-local HTTP endpoint that a compute identity (VM, function, or node) can query for instance attributes, user data, and temporary cloud credentials without storing long-lived keys on disk.
Why metadata services exist
Cloud instances need identity at boot: which account they belong to, which role to assume, which user-data script to run. Baking long-lived access keys into AMIs or images recreates the laptop-key problem at fleet scale.
A metadata service answers those questions over HTTP on a link-local address. The design is elegant for bootstrap and catastrophic when any process that can make outbound requests is treated as “the instance.”
How metadata is supposed to be used
The platform attaches an identity
A VM role, managed identity, or node service account is bound to the compute resource.
Local software queries the endpoint
Cloud-init, the instance agent, or the SDK calls the link-local URL for attributes and tokens.
Temporary credentials are issued
Short-lived keys are returned for that identity, not a user’s personal access key.
Cloud APIs are called as the instance
The SDK signs requests with those tokens. IAM decides what the role may do.
Tokens expire and are refreshed
Only processes that can still reach metadata can renew. That reachability is the real control.
What makes metadata dangerous
Credentials in an HTTP body
If any app can be tricked into fetching the URL, the response is often a usable cloud token.
Shared node identity
Every container on the VM inherits the same role unless workload identity splits it.
User-data and SSH keys
Bootstrap scripts and public keys in metadata can leak secrets that never appear in IAM.
Trust of “internal” URLs
Developers block the public internet and forget that 169.254.169.254 is still a reachable neighbor.
Metadata consumers compared
| Consumer | Legitimate use | Safer pattern |
|---|---|---|
| Cloud-init / instance agent | Bootstrap hostname, disks, and host tools | Keep user-data free of secrets; use a hardened IMDS |
| Node kubelet / CSI | Attach disks and talk to cloud APIs as the node | Minimal node role; no app pods on hostNetwork |
| Application SDK on a VM | Default credential chain for that instance role | Least-privilege instance profile; no SSRF in the app |
| Pod on a shared node | Almost never the node metadata role | Workload identity plus NetworkPolicy deny to link-local |
Metadata service hardening checklist
- Treat metadata credentials as production IAM: least privilege, no wildcard, no iam:PassRole unless required.
- Block application egress to link-local metadata addresses with NetworkPolicy, host firewalls, or IMDS hop limits.
- Do not put secrets, private keys, or long-lived tokens in user-data or custom metadata.
- Fix SSRF: deny link-local and localhost in server-side URL fetchers, redirects, and PDF/preview workers.
- Give pods their own workload identity instead of sharing the node’s metadata role.
- Prefer session-oriented metadata (see IMDS) over simple GET-without-headers where the provider offers it.
- Audit which processes actually call metadata; unexpected clients are an incident signal.
- Rotate and shrink the attached role immediately if metadata theft is suspected.
The practical takeaway
A metadata service is the cloud’s local identity API for compute. It exists so instances can obtain short-lived credentials without files full of keys.
Anything that can fetch that URL is the instance. Keep the role tiny, keep applications off the endpoint, and assume SSRF will try. The follow-on page on IMDS covers the VM-specific protocol details.
Related security terms
Instance Metadata Service (IMDS)
The VM-specific metadata service, including IMDSv1 versus session-oriented IMDSv2.
Server-Side Request Forgery (SSRF)
The application bug most often used to reach metadata from outside the instance.
Workload Identity
A narrower identity for pods and jobs that should not inherit the node metadata role.
Cloud IAM
The policies that decide how powerful a stolen metadata credential becomes.
Kubernetes Network Policy
Can block pods from reaching link-local metadata addresses.
Frequently asked questions
What is a metadata service in simple terms?
It is a tiny web API that only the machine (or node) is supposed to reach. The instance asks “who am I?” and “what role do I have?” and receives config plus temporary cloud tokens.
Why is the address often 169.254.169.254?
That is a link-local address. It is not routed across the internet. Reachability is meant to be limited to the host’s own network namespace—unless SSRF, hostNetwork, or a proxy breaks that assumption.
Is a metadata service the same as IMDS?
IMDS is the instance-scoped form used by VMs. Functions, GCE metadata, Azure IMDS, and some container platforms expose the same idea with different paths and headers.
What data can metadata expose?
Hostname, SSH keys, user-data scripts, placement, and—most critically—temporary credentials for the attached role or managed identity.
Why do attackers hunt metadata?
One HTTP GET can yield a cloud role that lists buckets, assumes other roles, or talks to the control plane. It turns an app bug into account-level access.
Should application pods query node metadata?
No. Pods should use workload identity with their own IAM role. Node metadata is for the kubelet, bootstrap, and host agents—not for business containers.
How do I reduce metadata risk without breaking the node?
Harden the service (session tokens, hop limits), block app network paths to it, shrink the instance role, and never pass user URLs into server-side fetchers.
References
Explore authoritative guidance and frameworks related to metadata service.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.