[receiver/awscloudwatchreceiver] Support for role_arn this will be used to allow the receiver do a multi stage assume role

[mglaserna]

The purpose and use-cases of the new component

Upon cross checking the codebase, i have saw that the awscloudwatchreceiver itself don't have the support for role_arn which will be a great help for having in a multi stage assume role kind of environment

Example configuration for the component

receivers:
awscloudwatch:
region: ap-southeast-1
role_arn: arn:XXXXXXXXXX
logs:
poll_interval: 10s
max_events_per_request: 50
groups:
autodiscover:
prefix: XXXXX

Telemetry data types supported

Logs data being pulled from a multi stage assume role

Is this a vendor-specific component?

• This is a vendor-specific component
• If this is a vendor-specific component, I am proposing to contribute and support it as a representative of the vendor.

Code Owner(s)

No response

Sponsor (optional)

No response

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/awscloudwatch: @djaglowski @schmikei

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[mglaserna]

As a workaround for Otel Collector Helm Chart Contrib, i was able to create a init container that would write to a emptydir for the assumerole config

and Added

  - name: AWS_SDK_LOAD_CONFIG
    value: "true"
    
 
Summarize:

  - name: aws-assume-role-temp-fix
    image: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/amazon/aws-cli
    imagePullSecrets: regcreds
    command: [/bin/sh, -c]
      # - "aws" 
      # - "sts" 
      # - "assume-role"
    args: 
      - |
        printf "[profile XXXXXXXXXXXXXXXXXX] \nrole_arn = X \nregion = ap-southeast-1a \nsource_profile = oXXXXXXXXX obs-cw\n" > /root/.aws/config
        printf "[profile XXXX] \nrole_arn = XXXXXXXXXXXXXXXXXX \ncredential_source=Ec2InstanceMetadata\n" >> /root/.aws/config
        
      Utilize IRSA assumerole
        

[crobert-1]

Hello @mglaserna, I believe the sigv4 authentication extension should be able to be used by the AWS cloud watch receiver to specify role_arn and assume a role. Can you test this and see if it fits your use case here?

[github-actions]

Pinging code owners for extension/sigv4auth: @Aneurysm9 @erichsueh3. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[nikmmd]

Dear maintainers,

I think this is still a relevant issue. In my use case, I want to use 1 EKS IRSA service account to assume another iam role in the account/cross account (to run multiple awscloudwatchreceivers in 1 pipeline, like awscloudwatch/acc1, awscloudwatch/acc2 etc).

I tried to get it to work with a current, profile based implementation. However, the aws credentials/config file that works with the aws cli, doesn't work with go aws sdk. The current ensureSession() impl seems to default to using the EC2 (instance profile role) instead of the IRSA role no matter what I do.

# /.aws/credentials
[default]
region=<region>
web_identity_token_file=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam:123456789:role/irsa-role
###

[profile acc1]
source_profile = default
role_arn=arn:aws:iam:123456789:role/acc1-role
###

After a quick poc, I find to get this to work, I need to call assume role via sdk to get this to work. I am able to contribute if you think this is relevant.

[djaglowski]

@nikmmd, it sounds like a reasonable need to me, though I'm not very familiar with many of the nuances here. If you submit a PR, we'll try to get it in.

[djaglowski]

Actually, I missed @crobert-1's comment. It sounds like this should be possible with the extension? Has this been tested?

[nikmmd]

@djaglowski I did not, as I don't see how I can map the extension and profiles together. I can see that sigv4auth extension does assume role, so I understand why it "may" work, but only if the inherited session context from sigv4auth is respected in the ensureSession() and then also for a selected profile when profile parameter is passed. I think the complexities with chaining aws sessions is why there is an issue in the first place.

Let me retest how this behaves attempting a similar flow and report back with details.

[niconosenzo]

Hey!

I can see that sigv4auth extension does assume role, so I understand why it "may" work

I can confirm that using the sigv4auth extension does not work either for IRSA authentication with cross-account roles. Assume role from the cli worked which would confirm the setup is correct.

@nikmmd do you have plans to go ahead with your poc ?

[nikmmd]

@niconosenzo hey, thanks for confirming. Sorry, I wasn't on top of this. I can find time this weekend to wrap up for PR and we can go from there.

[niconosenzo]

Thanks @nikmmd !, Btw, if I'm seeing it correctly the assume role bits are already there as a connection util package, we might make use of it probably ?

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• extension/sigv4auth: @Aneurysm9 @erichsueh3
• receiver/awscloudwatch: @djaglowski @schmikei

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

This issue has been closed as inactive because it has been stale for 120 days with no activity.