schibsted
AWS profiles conflict with AWS variables exported in shell
ISSUE TYPE
- Documentation Report
OS / ENVIRONMENT
*nix
SUMMARY
When I have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY exported in my .bashrc, then these are preferred to the credentials that are stated in my ~/.aws/credentials, in that way setting --profile doesn't take any effect
EXPECTED RESULTS
Could you please add this to the documentation? https://github.com/schibsted/strongbox/wiki/MFA
@emilva I digged a big deeper and now I think that it's actually a bug. https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html Take a look at the section below, about the precedence of credentials. It says, that if you specify "-- profile" in the command line, it should precede the ENV variables. But in your case, in doesn't. Env vars still win. This works well, in for example https://github.schibsted.io/spt-infrastructure/rhea
I see! It looks like Strongbox is reading ENV before System Properties and then Profile credentials. Maybe @stiankri can clarify if there was a specific reason for this ordering. If not we can probably rearrange it to follow the cli conventions. https://github.com/schibsted/strongbox/blob/master/sdk/src/main/java/com/schibsted/security/strongbox/sdk/internal/config/credentials/CustomCredentialsProviderChain.java
Thanks for reporting this and apologies for not responding sooner. The goal is to be compatible with the AWS CLI so explicitly specifying --profile should indeed take precedence.
Backdrop We started out from the AWS Java SDK's DefaultAWSCredentialsProviderChain. The Java SDK is unfortunately not compatible with the AWS CLI. In particular it was not able to handle MFA and assuming roles when using profiles, which is why we made our own CustomCredentialsProviderChain, with an improved ProfileCredentialProvider, but otherwise keeping the chain ordering (i.e. a step in the right direction).
Making the changes
Care must be taken when implementing this to not brake other expected behavior. We might be able to check if the profile is explicitly set and then call the ProfileCredentialProvider directly, rather than using the chain? At the same time it would make sense to go over the other rules to see if there is something else we have missed.
