Dependent jar changing the default behaviour from STS

[gabrielfmagalhaes]

Hello, I've always used AWS SDK 2.0 clients (e.g., SQS, SNS) and provided credentials automatically by using STS (probably with Web Federation, since our applications are hosted in EKS). I never had to worry about STS code configuration (it did the work simply by adding the dependency), but after adding the kinesis-client lib, my application lost all of the default credentials and I had to manually provide them using STS's AssumeRoleWithWebIdentity. Is that supposed to happen?

My code was something like that

...
@Bean
public SqsAsyncClient sqsAsyncClient() {
   return SqsAsyncClient.builder().region(region).build();
}

@Bean
public SnsAsyncClient sqsAsyncClient() {
   return SnsAsyncClient.builder().region(region).build();;
}
...

and for dependencies, I had those

...
implementation 'software.amazon.awssdk:sts'
implementation 'software.amazon.awssdk:sns'
implementation 'software.amazon.awssdk:sqs'

implementation 'software.amazon.kinesis:amazon-kinesis-client:2.4.1'
...

[gaddam1987]

We also faced similar issue with Kinesis when running in EKS. Default credentials is not picking the Web Identity Token from AWS STS

[joshng]

9 months later, this still appears to be an issue: we have a ServiceAccount/IAM-role that is assigned to a KCL process in EKS using the same mechanism we successfully employ elsewhere in our stack, but the KCL somehow undermines the default STS-based credentials strategy, and fails to assume the intended role.

Also, in attempting to find a workaround for this by updating the KCL to a version newer than 2.4.5, we encountered https://github.com/awslabs/amazon-kinesis-client/issues/1068 ... So now the instabilities with this library are driving us to consider abandoning kinesis entirely and switching to kafka.