During a threat hunting exercise, a security analyst reviews network logs from a Kubernetes host node running enterprise microservices. The log entries indicate that a compromised container instance successfully issued a request to extract infrastructure credentials:
[2026-07-20 09:14:02 UTC] TCP 10.244.1.45:49152 -> 169.254.169.254:80 GET /latest/meta-data/iam/security-credentials/node-role HTTP/1.1
[2026-07-20 09:14:02 UTC] HTTP 200 OK (Content-Length: 1248, IAM Role: NodeInstanceRole)
[2026-07-20 09:14:15 UTC] AWS STS API call initiated directly from container IP 10.244.1.45 using retrieved token
Which host and architecture vulnerability is the root cause of this credential exposure?
- Reliance on Instance Metadata Service Version 1 (IMDSv1) without session tokens, combined with unrestricted container access to the host link-local metadata endpointCevap
- BReliance on network perimeter firewalls that assume internal container traffic is inherently trusted and does not require outbound metadata filtering
- CAbsence of an inline Web Application Firewall (WAF) to inspect incoming external HTTP request headers before they reach the pod
- DFailure of host-based intrusion prevention systems to detect SQL injection payloads embedded inside the HTTP request URI
Cevap
Reliance on Instance Metadata Service Version 1 (IMDSv1) without session tokens, combined with unrestricted container access to the host link-local metadata endpoint
The root cause vulnerability is the reliance on Instance Metadata Service Version 1 (IMDSv1), which processes unauthenticated HTTP GET requests for cloud node IAM credentials, paired with a lack of host network namespace isolation for container workloads. Because IMDSv1 does not require session tokens (unlike IMDSv2), any process or container with access to the link-local IP 169.254.169.254 can extract the host's IAM role credentials and assume those privileges.
Adım Adım Çözüm
Anahtar Kavram
Cloud Host Instance Metadata Service Vulnerabilities (IMDSv1 vs IMDSv2) and Workload Egress Isolation