Closed JamesFrost closed 5 years ago
The AWS credential lookup chain, while defined more or less standard across the various language SDKs, do have some ambiguity when it comes to handling cases where env vars for the different credential providers were set at the same time, which would result in some unexpected behavior for the command getting executed through runas. This seemed like the easiest solution vs. trying to define the behavior for each and every AWS sdk.
Coming in the 1.4 release, we're actually going to start depending on the behavior of the AWS_PROFILE getting unset, since we're going to use a credential provider further down the chain (the ECS URI provider) in order to provide a local endpoint which can track the expiration, and automatically refresh, the role credentials in the middle of the execution of a long-running command.
@mmmorris1975 Thanks for the explanation 👌
The only restriction I have to adhere to on my end is to ensure that I'm driving the downstream application towards a particular path to get credentials. If it would be helpful, I could redirect/rename that inbound AWS_PROFILE variable to something that the downstream AWS library wouldn't pick up. Something like AWSRUNAS_PROFILE, or something like that
That would be great - it would solve the problem that we have 👍
Hey, sorry for the delay in getting this out. You should be able to use version 1.3.5 to get this functionality
@mmmorris1975 Just tried this and it has solved my problem. Thanks for all your work - I use this project every day 😎
Glad to hear you find it useful :)
https://github.com/mmmorris1975/aws-runas/blob/master/docs/configuration.md#environment-variables
Is there a reason for this? I would like to be able to access this environment variable in a command I've run using
aws-runas
.For example, I would like to be able to generate an S3 bucket name that has the AWS profile name in.