Common features
Named clients
This feature is new and was initially designed to allow overriding credentials per named client. Feel free to open an issue to propose enhancements. |
You can inject named clients with different configurations. To do this, annotate your injection point with @AmazonClient
.
import io.quarkiverse.amazon.common.AmazonClient;
public class DynamoDbEnhancedClientTest {
@Inject
@AmazonClient("custom")
DynamoDbClient clientNamedCustom;
Named clients inherit the configuration of the unamed client but you can override them.
quarkus.dynamodb.custom.aws.credentials.type=static
quarkus.dynamodb.custom.aws.credentials.static-provider.access-key-id=xxx
quarkus.dynamodb.custom.aws.credentials.static-provider.secret-access-key=yyy
Overriding the client configuration
You can override the client configuration by adding a custom producer that will further configure the client builder built by the extension.
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClient;
import software.amazon.awssdk.services.dynamodb.DynamoDbAsyncClientBuilder;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.DynamoDbClientBuilder;
@ApplicationScoped
public class DynamodbProducer {
private static final DynamoDBModifyResponse EXECUTION_INTERCEPTOR = new io.quarkiverse.it.amazon.dynamodb.DynamoDBModifyResponse();
@Produces
@ApplicationScoped
public DynamoDbClient createDynamoDbClient(DynamoDbClientBuilder builder) {
builder.overrideConfiguration(
c -> c.addExecutionInterceptor(EXECUTION_INTERCEPTOR));
return builder.build();
}
@Produces
@ApplicationScoped
public DynamoDbAsyncClient createDynamoDbClient(DynamoDbAsyncClientBuilder builder) {
builder.overrideConfiguration(
c -> c.addExecutionInterceptor(EXECUTION_INTERCEPTOR));
return builder.build();
}
}
Custom AWS credentials provider
When configuring credentials type for a given client, you may not find the supported methods fit your context. In such case, you can implement
and provide your own AwsCredentialsProvider
as a bean.
As an example, we will implement a provider for a S3 client application hosted in EKS.
The provider named eks-iam
can be implemented with a @Produces
method:
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;
import software.amazon.awssdk.auth.credentials.AwsCredentialsProvider;
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider;
@Produces
@ApplicationScoped
@Named("eks-iam")
public AwsCredentialsProvider getAwsCredentialProvider() {
String tokenFile = System.getenv("AWS_WEB_IDENTITY_TOKEN_FILE");
String roleArn = System.getenv("AWS_ROLE_ARN");
return (tokenFile != null && roleArn != null)
? WebIdentityTokenFileCredentialsProvider.builder()
.webIdentityTokenFile(Paths.get(tokenFile))
.roleArn(roleArn)
.build()
: DefaultCredentialsProvider.create();
}
Configure the default S3 client to use the custom provider for authentication:
quarkus.s3.aws.credentials.type=custom
quarkus.s3.aws.credentials.custom-provider.name=eks-iam
As this provider use WebIdentityTokenFileCredentialsProvider
, add the following dependency to the application pom.xml
:
<dependency>
<groupId>io.quarkiverse.amazonservices</groupId>
<artifactId>quarkus-amazon-sts</artifactId>
</dependency>
Docker image build with AWS CRT
Since AWS CRT version 0.31.0, native library must be embedded in the docker image. This is not done by default. To do this, you need to :
-
edit .dockerignore to add:
!target/*.so !target/ *.properties
-
edit Dockerfile.native to add a line that copies *.so files and *.properties:
# Shared objects to be dynamically loaded at runtime as needed, COPY --chown=1001:root target/*.properties target/*.so /work/