AWS Java Core SDK 1.12.x - DefaultCredentialsProviderChain

[vpeddada-tibco]

Describe the bug

Hi Team,

We have recently migrated the AWS Java SDK for S3 and it's dependencies from 1.11.x to 1.12.x. During the course of evaluation, we observed that for DefaultCredentialsProviderChain type of authentication using the Credential profiles file at the default location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI, the SDK is not able to detect the role_arn for cross account access from the config file.

However if we provide the role_arn in credentials file, then it's picking it up successfully. Until 1.11.x it's working in line with AWS CLI where it reads the AWS Credentilas from Credentials file and role_arn from Config file.

Hence we would like to know if changes have been induced in the AWS Core SDK in 1.12.x or if this is a defect in the SDK as the behavior changed from 1.11.x to 1.12.x.

Expected Behavior

Ideally the SDK should be able to read role_arn from config file as per the older version of the SDK.

Current Behavior

Currently with 1.12.x version the SDK couldn't read the role_arn from config file.

Reproduction Steps

• credentialsProvider = new DefaultAWSCredentialsProviderChain();
  AmazonS3Client s3client =AmazonS3ClientBuilder.standard()
  .withCredentials(credentialsProvider).build();
  Configure the Credential profiles file at the default location (~/.aws/credentials) shared by all AWS SDKs and the AWS CLI.
  Provide role_arn in config file.

Possible Solution

I have checked the changelog from https://github.com/aws/aws-sdk-java/blob/master/CHANGELOG.md location but couldn't find any references of DefaultCredentialsProvider. Hence I request you to clear this query if this change of behavior is intentionally induced by the SDK team

Additional Information/Context

However if we provide the role_arn in credentials file, then it's picking it up successfully. Until 1.11.x it's working in line with AWS CLI where it reads the AWS Credentials from Credentials file and role_arn from Config file.

AWS Java SDK version used

1.12.411

JDK version used

1.8

Operating System and version

Windows 10

[debora-ito]

Which version of 1.11.x exactly were you using?

One change that could have impacted role_arn is that in SDK version 1.11.704 we increased the priority of WebIdentityTokenCredentialsProvider in the Default Credential Provider Chain, but we didn't change how the role_arn value was read.

Can you show a sample of how your credentials file and config file looks like?

[vpeddada-tibco]

Hi @debora-ito ,

Thank you for your response.
We were using SDK version 1.11.967 earlier.

Please find the attachments for the credentials and config files. Also, I attached the AWS SDK debug logs for your reference.
From the debug log with timestamp 2023-07-25T15:20:26,539, you can find that it tries to load the credentials from the Profile but didn't make the STS call using the role_arn provided in the config file. Hence my application failed with Access denied error for PUT operation.

Let me know if you need any additional information.

Thanks
Varenya

CredFiles&Debug.zip

[vpeddada-tibco]

Hi @debora-ito ,

Do you have any further update on this issue?

[debora-ito]

@vpeddada sorry for the silence, I'll take a look at the logs shortly.

[debora-ito]

@vpeddada I found the change that may have impacted this.

We have an old feature request (#803) asking to make assume role properties in the credentials and config files in the Java SDK more similar to the AWS CLI behavior - you can read more details on the issue over there.

While we can't make the asked changes without breaking backwards compatibility, in version 1.12.79 released in Oct. 2021 (changelog) there was a change to -

Fall back to 'profile X' if the SDK is configured with profile 'X' and 'X' does not exist in the SDK configuration files. No longer log when a configuration file includes 'profile X'.

What I'm finding weird is that after the change, having the role_arn in the config file should work.

I'm still investigating this.

[debora-ito]

Actually I tried to reproduce the issue locally but I couldn't, in both older and newer versions.

Are you sure the role_arn is not being picked up from the config file?
For debugging purposes, does it work if you call ProfileCredentialsProvider directly, instead of the Default Credential Provider Chain?

[github-actions]

It looks like this issue has not been active for more than five days. In the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please add a comment to prevent automatic closure, or if the issue is already closed please feel free to reopen it.