Unexpected sourceIPAddress in GetCallerIdentity CloudTrail events from EKS pods using EC2 instance role

The sourceIPAddress in CloudTrail logs for GetCallerIdentity calls from EKS pods doesn't match your EC2 instance's Elastic IP because these calls aren't actually going through your EC2 instance's network interface.

When pods in an EKS cluster use IAM roles (whether through the EC2 instance role or through EKS Pod Identity), the authentication flow works differently than you might expect. The GetCallerIdentity API calls you're seeing with the Go-http-client/1.1 user agent are likely coming from the EKS control plane or the EKS Pod Identity Agent.

For EKS Pod Identity specifically, the system uses a special metadata service endpoint (169.254.170.23) rather than the standard EC2 instance metadata service (169.254.169.254). This is part of how EKS manages identity and credentials for pods.

The sourceIPAddress you're seeing in CloudTrail is likely the IP address of AWS's internal service infrastructure that's making the actual STS calls on behalf of your pods, not your EC2 instances themselves. This is why it doesn't match any of your known public-facing resources.

This behavior is by design - the credential vending and identity verification process for EKS pods is handled through AWS's infrastructure, which is why the source IP appears to be from AWS's internal network rather than from your EC2 instances' Elastic IPs.
Sources
When this AWS "GetCallerIdentity" API Call will get triggred | AWS re:Post
Unsupported Host for AWS CLI and Boto3 inside an EKS cluster | AWS re:Post

Great question,we've run into similar observations in EKS setups.

Why the sourceIPAddress in CloudTrail doesn't match the EC2 EIP: Even though your pods are running on EC2 instances with Elastic IPs (EIPs), the actual network call to sts:GetCallerIdentity may not originate directly from your node’s public IP. Here’s why:

EC2 instance metadata proxying (IMDSv2 + EKS): Pods using the instance role (via default service account or IRSA fallback) access the role credentials via the instance metadata service (IMDS). When a pod makes an STS call like GetCallerIdentity, the request may use the default network route and not necessarily go through the EIP. It might route through the primary ENI, or even use the control plane path (EKS-managed components).

NAT and control plane activity: If the node has access to a NAT Gateway, or if certain calls are relayed or initiated by the EKS control plane (e.g., kubelet heartbeat checks or identity sync), the originating IP can come from AWS-owned IP space — not your public EIP. That explains the unknown IPs you see in CloudTrail.

Go-http-client/1.1 user agent = kubelet or container SDKs: That user agent is common with requests coming from: The AWS SDK for Go, which many Kubernetes components use Kubelet running on nodes Sidecar containers or internal EKS agents

In short Summary: This behavior is expected and does not indicate compromise. The sourceIPAddress field in CloudTrail doesn’t always reflect the EC2 instance's EIP, especially for STS calls inside EKS. If you want more deterministic IP behavior, you'd need to route pod traffic through a NAT Gateway or an Egress-only setup with known IPs, but that defeats some of the simplicity of public subnet nodes.

Let me know if you want help tracing specific IPs, you can often look them up in the AWS IP ranges JSON to confirm they're owned by AWS.

https://ip-ranges.amazonaws.com/ip-ranges.json