ec2 client credential init fix for AWS IRSA

[Greyeye]

What does this PR do?

This PR modifies the initialisation of the AWS EC2 client to use the AWS configuration package. This change enables support for built-in credentials such as AWS IAM Roles for Service Accounts (IRSA). The current use of ec2.New() does not work with IRSA, and although not tested, a similar issue likely occurs with EKS Pod Identity as well.

When a pod is assigned an IRSA with the correct permissions to perform DescribeTags, it encounters an error and logs the following message:

(pkg/util/ec2/ec2_tags.go:104 in fetchEc2TagsFromAPI) | unable to get tags using default credentials (falling back to instance role): operation error EC2: DescribeTags, https response error StatusCode: 400, RequestID: 1234-1234-1234, api error MissingParameter: The request must contain the parameter AWSAccessKeyId

fixes issue 29916

Motivation

We are currently running the Datadog Agent pod in AWS EKS and are aiming to clean up the instance role by eliminating unnecessary permissions attached to it. Datadog is one of many services that currently use the instance role for the ec2:DescribeTags permission, and we would like to switch to using the IRSA-assigned role.

After extensive debugging and tracing, we discovered that when the pod is assigned an IRSA token but the instance is running IMDSv2, it fails to use IRSA and always falls back to using the instance role.

Describe how to test/QA your changes

1. create a new EKS node and instance role that does not allow ec2:describeTags.
2. create a new AWS IAM Rolewith ec2:describeTags, and attach this to datadog-agent using IRSA
3. deploy datadog-agent with config.yaml (or using configMap) like this
   collect_ec2_tags: true
   collect_ec2_tags_use_imds: true
   ec2_prefer_imdsv2: true
4. start the datadog-agent and verify the role gets used, and tags are collected using the IRSA role.

Possible Drawbacks / Trade-offs

none

Additional Notes

none

[bits-bot]

All committers have signed the CLA.