You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to use EKS pod identities to grant the provider access to AWS, as an alternative to IRSA
How could Crossplane help solve your problem?
By adding support for this authentication method in ProviderConfig.
FWIW, I did attempt to use a pod identity with a ProviderConfig set to use IRSA credentials, hoping that it might "just work" given that both IRSA and pod identities work by automatically injecting AWS environment variables into the pod. This approach failed, but I no longer have the exact error message, sorry. Some googling at the time suggested that it might be necessary to use version 2 of the AWS Go client with EKS pod identities.
The text was updated successfully, but these errors were encountered:
From what I can find with other controllers with the same issue, all that needs to be done is updating the aws sdk dependency. The EKS provider is still using the old sdk, instead of v2.
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with/fresh will mark this issue as not stale.
What problem are you facing?
I would like to use EKS pod identities to grant the provider access to AWS, as an alternative to IRSA
How could Crossplane help solve your problem?
By adding support for this authentication method in
ProviderConfig
.FWIW, I did attempt to use a pod identity with a
ProviderConfig
set to useIRSA
credentials, hoping that it might "just work" given that both IRSA and pod identities work by automatically injecting AWS environment variables into the pod. This approach failed, but I no longer have the exact error message, sorry. Some googling at the time suggested that it might be necessary to use version 2 of the AWS Go client with EKS pod identities.The text was updated successfully, but these errors were encountered: