-
Notifications
You must be signed in to change notification settings - Fork 951
Description
Describe the bug
Contrary to WebIdentityTokenFileCredentialsProvider which allows a missing web idenity token file in its constructor to throw the loadException lazily on calls to resolveCredentials the StsWebIdentityTokenFileCredentialsProvider implementation throws this exception in its constructor.
This looks inconsistent and is not reflected in the javadoc of WebIdentityTokenFileCredentialsProvider that hints that it is more or less a 1:1 replacement implementation.
* StsWebIdentityTokenFileCredentialsProvider in sts package can be used instead of this class if any one of following is
* required
* <ul>
* <li>Pass a custom StsClient to the provider. </li>
* <li>Periodically update credentials </li>
* </ul>
It cannot be used as an oob replacement in a custom DefaultCredentialProvider.provideChain implementation despite the code documentation indicates that.
} catch (RuntimeException e) {
// If we couldn't load the credentials provider for some reason, save an exception describing why. This exception
// will only be raised on calls to getCredentials. We don't want to raise an exception here because it may be
// expected (eg. in the default credential chain).
loadExceptionLocal = e;
}
Regression Issue
- Select this option if this issue appears to be a regression.
Expected Behavior
Consistent implementation with WebIdentityTokenFileCredentialsProvider, allows the creation and usage in a "custom provider chain" implementation and throws the loadException only when the credentials need to be resolved.
Current Behavior
Exception is thrown in constructor when credentials provider cannot be created (eg. web identity token file is missing)
Reproduction Steps
eg.
create some custom DefaultCredentialsWithStsFallbackProvider (copy of DefaultCredentialsProvider) that supports a custom StsClient implementation:
AwsCredentialsProvider awsCredentialsProvider = DefaultCredentialsWithStsBackProvider.builder()
.stsClientWithFallback(stsClient).build();
S3AsyncClient.builder().credentialsProvider(awsCredentialsProvider).build();
and use it in the provider chain:
/**
* Create the default credential chain using the configuration in the provided builder.
*/
private static LazyAwsCredentialsProvider createChain(Builder builder) {
boolean asyncCredentialUpdateEnabled = builder.asyncCredentialUpdateEnabled;
boolean reuseLastProviderEnabled = builder.reuseLastProviderEnabled;
return LazyAwsCredentialsProvider.create(() -> {
AwsCredentialsProvider[] credentialsProviders = new AwsCredentialsProvider[] {
SystemPropertyCredentialsProvider.create(),
EnvironmentVariableCredentialsProvider.create(),
StsWebIdentityTokenFileCredentialsProvider.builder()
.asyncCredentialUpdateEnabled(asyncCredentialUpdateEnabled)
.stsClient(builder.stsClientWithFallback) // use the client with fallback endpoints
.build(),
ProfileCredentialsProvider.builder()
.profileFile(builder.profileFile)
.profileName(builder.profileName)
.build(),
ContainerCredentialsProvider.builder()
.asyncCredentialUpdateEnabled(asyncCredentialUpdateEnabled)
.build(),
InstanceProfileCredentialsProvider.builder()
.asyncCredentialUpdateEnabled(asyncCredentialUpdateEnabled)
.profileFile(builder.profileFile)
.profileName(builder.profileName)
.build()
};
return AwsCredentialsProviderChain.builder()
.reuseLastProviderEnabled(reuseLastProviderEnabled)
.credentialsProviders(credentialsProviders)
.build();
});
}
Possible Solution
Do not throw the exception in StsWebIdentityTokenFileCredentialsProvider constructor but do it consistent with the implementation in WebIdentityTokenFileCredentialsProvider.
maybe a "larger" try-catch block is good enough.
Additional Information/Context
No response
AWS Java SDK version used
software.amazon.awssdk:sts:2.36.1
JDK version used
Java 21.0.8
Operating System and version
linux, debian 12