aws-secretsmanager-jdbc: Error while using aws-secretsmanager with aws-java-sdk-sts

Hi, I’m working to deploy spring boot applicaiton with aws-secretsmanager-jdbc integrated. It works fine with the the usual flow where I set AWS_ACCESS_KEY_ID and and VALUE in env variable. when i’m trying to deploy the app in eks, ive created a service role with access to a particular secret, and included aws-java-sdk-sts to assume the role which is injected in the pod. when i’m not adding the sdk-sts to pom, it tries to assume the role of the managed nodes, which doesn’t have access to secrets. whenever I add the above library, it is able to assume the proper role but gives the below stack trace.

Caused by: java.lang.StackOverflowError: null
        at java.base/java.lang.ClassLoader.defineClass1(Native Method)
        at java.base/java.lang.ClassLoader.defineClass(Unknown Source)
        at java.base/java.security.SecureClassLoader.defineClass(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(Unknown Source)
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
        at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:744)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:704)
        at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:686)
        at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:550)
        at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:530)
        at com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.doInvoke(AWSSecurityTokenServiceClient.java:1369)
        at com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.invoke(AWSSecurityTokenServiceClient.java:1338)
        at com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.invoke(AWSSecurityTokenServiceClient.java:1327)
        at com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.executeAssumeRole(AWSSecurityTokenServiceClient.java:488)
        at com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient.assumeRole(AWSSecurityTokenServiceClient.java:460)
        at com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider.newSession(STSAssumeRoleSessionCredentialsProvider.java:321)
        at com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider.access$000(STSAssumeRoleSessionCredentialsProvider.java:37)
        at com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider$1.call(STSAssumeRoleSessionCredentialsProvider.java:76)
        at com.amazonaws.auth.STSAssumeRoleSessionCredentialsProvider$1.call(STSAssumeRoleSessionCredentialsProvider.java:73) ```

is there a way to use AWS_WEB_IDENTITY_TOKEN_FILE instead of aws creds to access the secrets

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 16 (3 by maintainers)

Most upvoted comments

Maybe I confused you. So, let me explain.

If the sts dependency is not present in the classpath (i.e. not inside build.gradle for my case), it will use the node’s IAM role, which is something we do not want, as you also said. When we add the sts dependency, it uses the service account role. In order to achieve this with this specific library, it seems that you need to add the v1 of this sts dependency (i.e. com.amazonaws:aws-java-sdk-sts:1.11.1004). I am using version 1.0.6 of the aws-secretsmanager-jdbc library

I hope it is more clear now!

ktzevelekidis on Apr 27, 2021

You can’t use the V1 version of the AWS SDK STS library ('com.amazonaws`) with version 2 of the JDBC caching library, and vice versa.

It’s worth nothing that the Java SDK changed classpaths when moving from V1(com.amazonaws) to V2 (software.amazon.awssdk). However, additional libraries vended by AWS like the crypto SDK and this library did not change their classpaths. This was intentional, but I understand the confusion.

If you want to use the V2 SDK, make sure to add version 2 of this library to your project file, and vice versa.

simonmarty on Nov 15, 2023

@ktzevelekidis

Maybe I confused you. So, let me explain.

If the sts dependency is not present in the classpath (i.e. not inside build.gradle for my case), it will use the node’s IAM role, which is something we do not want, as you also said. When we add the sts dependency, it uses the service account role. In order to achieve this with this specific library, it seems that you need to add the v1 of this sts dependency (i.e. com.amazonaws:aws-java-sdk-sts:1.11.1004). I am using version 1.0.6 of the aws-secretsmanager-jdbc library

I hope it is more clear now!

This needs to be made clear and more visible. Thanks for the solution.

spirosag on Feb 2, 2023

Thank you for opening this issue - we are looking into it.

willtong1234 on May 26, 2021