[processor/resourcedetection] Support EKS Auto Mode cluster

[dloucasfx]

Component(s)

[processor/resourcedetection]

What happened?

Description

EKS Auto Mode cluster does not provide IMDS access unless the pod is running in hostNetwork .

https://docs.aws.amazon.com/eks/latest/userguide/automode-learn-instances.html#_instance_metadata_service

If a pod absolutely requires IMDS access when running in Auto Mode:
The pod must be configured to run with hostNetwork: true
This allows the pod to access the instance metadata service directly

This is problematic if the pod is not running with hostNetwork as the following detectors and functionalities that pull data from the ec2 metadata server will fail:

1- ec2 detector uses the metadata server to set the following attributes https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/resourcedetectionprocessor/internal/aws/ec2/ec2.go#L110-L115 and we need to find an alternative way using the instance.
Suggestion:

• use the k8s api to get the node description and check the ProviderID to parse the instanceID and region.
• use the AWS api to describe the instanceID and pull the remaining info needed to set the ec2 detector attribute
• this solution is only for ec2 instances running as nodes in k8s cluster, so we need to either have a separate ec2-eks detector or add an option to the existing ec2 detector, example: eks, to signal the logic to use this alternate approach

2- eks detector. In addition to this fix #39486 , the following functionality that depends on IMDS will fail.

• k8s.cluster.name
• cloud.account.id
  This can also be fixed with similar approach as above, ie: use the ProviderID to get the region and instanceID ....

Steps to Reproduce

Install the collector in k8s EKS Auto Mode cluster and make sure the pods are not in hostnetwork.
Also make sure you have a resource detection processor with eks (k8s.cluster.name and cloud.account.id set to true) and ec2 detector enabled

Expected Result

All resource attributes are discovered correctly.

Actual Result

Errors:

2025-04-18T16:20:26.893Z	warn	eks/detector.go:155	Unable to get EKS cluster name	{"error": "operation error ec2imds: GetRegion, exceeded maximum number of attempts, 3, http response error StatusCode: 401, request to EC2 IMDS failed"}

Collector version

main

Important Note

While developing the above suggestion, I have noticed that AWS API client gets its auth credentials through the metadata server endpoint. In other words, we can no longer "transparently" use AWS API calls in EKS AUTO MODE (non hostnetwork pod) as this endpoint is not reachable.
This means that the user needs to explicitly define the AWS credentials. This can be done through different means, example, env variables or using POD Identity.
Pod Identity is the best choice as the agent identity is pre-installed in EKS Auto Mode and the user will only need to create the appropriate role and associate it with the pod SA.

[github-actions]

Pinging code owners for processor/resourcedetection: @Aneurysm9 @dashpole. See Adding Labels via Comments if you do not have permissions to add labels yourself. For example, comment '/label priority:p2 -needs-triaged' to set the priority and remove the needs-triaged label.

[dmitryax]

I think all the EC2 related metadata that can be captured via k8s API in the EKS Auto mode can go to eks detector even if the generated attributes conflict with those that provided by the ec2 detector. I should pretty clear for the end users