Capa fix hardcoded role arn for aws iam authenticator

[AmitSahastra]

/kind bug

What steps did you take and what happened: ARN hardcoded with ":aws:" partition do not work with "us-gov" cloud. Implementation

Issue: For few roles/policies arn partition is hardcoded to "aws". While working with "aws-us-gov" cloud partition this does not work and cluster creation failed.

What did you expect to happen: ARN should resolve to "aws-us-gov" partition instead of default "aws" partition.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.] Initial PR can be found here

Environment:

• Partition: aws-us-gov
• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

[dlipovetsky]

Thanks for filing this @AmitSahastra!

I see that the clusterawsadm CLI uses a default "partition" value to derive ARNs, and does not "discover" facts (such as region) about the user's AWS environment. I think it makes sense for this CLI to allow the user to define a "partition" value.

I am not sure we need to change controllers to be aware of the "partition" in an ARN. Controllers should, and in most cases already do, use names to identify resources. Whenever an AWS API expects an ARN from the client, the controllers should ask AWS to translate the name into the ARN. The controllers themselves should probably not translate the name to ARN.

The work in https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/4011 has introduces a function that asks AWS to translate the Role to its ARN. We should probably have similar functions for other kinds of AWS resources, or perhaps a single generic function, if appropriate.

What do you think?

[dlipovetsky]

/triage accepted /priority important-longterm

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten