AWS IAM authentication -- wrong IAM role is assumed

[binaryoak]

Describe the bug hello, I am using 2.2.1 of spring cloud vault, the issue I am facing is: my services are deployed in a aws EKS cluster, and every service has its own IAM role, and the IAM roles are associated with service accounts(refer to https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/), in short words, we are using IAM roles at pod level.

according to the doc:

The current IAM role the application is running in is automatically calculated. If you are running your application on AWS ECS then the application will use the IAM role assigned to the ECS task of the running container. If you are running your application naked on top of an EC2 instance then the IAM role used will be the one assigned to the EC2 instance.

but I am not sure how does the IAM role is calculated in this situation, the IAM role it calculates out is the IAM role of the EKS node, not the one we used at pod level, in other words, not the IAM role the running application is using.

Sample there is no customised config, all is following the instructions in official doc.

[mp911de]

We don't have many insights into AWS specifics. We default to DefaultAWSCredentialsProviderChain.getInstance() that tries to obtain credentials from env variables, system properties, a web identity token, or the EC2/container credentials.

Please let us know if there's anything else we can help with or whether we can close this ticket.

[binaryoak]

exactly, that's what I got after I checked the source code. but that's for credentials, right? can you help me understand the process that how The current IAM role the application is running in is automatically calculated. happens? thanks

[mp911de]

The role ARN is determined by the signature, as AWSCredentials are included in the actual signature. So it boils down to the actual credentials that are being used.

[binaryoak]

hmm, I see. then it is really a bit strange, in my case, web token identity should be used, but according to current behaviour, it still goes for the instance profile...but there is no IntanceProfileCredentialsProvider in the default chain, btw, I am using asw-sdk-core 1.11.666

[mp911de]

You can register a ClientAuthentication yourself with the correct AWS credential provider if the default bean interferes with your setup.

[binaryoak]

sounds a promised way, can you provide me sample codes?

[mp911de]

You're still using the bootstrap context, so you need to provide a @Bean in a configuration class that is registered with the bootstrap context via spring.factories.

Check out the bean registration at https://github.com/spring-cloud/spring-cloud-vault/blob/main/spring-cloud-vault-config-consul/src/test/resources/META-INF/spring.factories#L2-L3 and https://github.com/spring-cloud/spring-cloud-vault/blob/main/spring-cloud-vault-config-consul/src/test/java/org/springframework/cloud/vault/config/consul/VaultConfigConsulBootstrapConfigurationTests.java#L67.

In your case, you need to define a ClientAuthentication bean instead of the showed ConsulSecretBackendMetadataFactory.

[mp911de]

Closing due to lack of activity.

[jkuipers]

Just ran into this myself after porting over my own old parameter store integration to the spring-cloud-starter-aws-parameter-store-config module. It doesn't provide a transitive dependency on com.amazonaws:aws-java-sdk-sts, so you'll have to add that to your application yourself to make this work.

[mp911de]

Do you think we could improve our documentation somehow? Happy to review a PR or similar.

[jkuipers]

It's not really related to your project, it's basically how the AWS SDK works; their credentials provider chain will handle everything as long as you have the right dependency on the classpath. I left a comment here because I found this issue while googling for what I had done wrong when I started to use the spring-cloud-aws provded Parameter Store integration, so I figured I'd leave a comment for other people stumbling upon the same thing.