s3deploy credentials sourcing about s3deploy HOT 3 CLOSED

Was this behavior introduced with the latest releases? Is this a regression?

I recently upgraded to v2 of the AWS SDK. But I did at the same time add a fair amount of integration tests. It's hard to for me to judge what's happening on your end without knowing the details, but I can just add that I'm using this fine using aws-vault, which sets these env vars.

Also see the working integration test here:

https://github.com/bep/s3deploy/blob/master/testscripts/basic.txt

I suspect that v1 AWS SDK had some mysterious fall back authentication for when these keys/secret were not provided as a flag or OS env, but I don't think I'm prepared to spend time on retracing that as I suspect there are workarounds for this that I suspect in the end is a better solution.

from s3deploy.

Thanks for the super quick turn around. Yes I was looking at the change history and I was wondering if the AWS SDK v2 was what changed the previous behavior. I will spend more time looking into this. Thanks!

from s3deploy.

Just in case someone is looking for a similar solution and lands on this issue, here is an update: I was able to work around my problem by implementing the steps in this StackOverflow post. It is possible to add these three steps in the buildspec:

      - TOKEN=$(curl http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI)
      - export AWS_ACCESS_KEY_ID=$(echo "${TOKEN}" | jq -r '.AccessKeyId')
      - export AWS_SECRET_ACCESS_KEY=$(echo "${TOKEN}" | jq -r '.SecretAccessKey')
      - export AWS_SESSION_TOKEN=$(echo "${TOKEN}" | jq -r '.Token')

And then eventually run the command with the -key and -secret flags:

      - s3deploy -bucket $BUCKET -source ./public/ -v -region $REGION -key $AWS_ACCESS_KEY_ID -secret $AWS_SECRET_ACCESS_KEY  

I don't know if this is an issue with the s3deploy code or with the SDK but I assume(d) that the $AWS_CONTAINER_CREDENTIALS_RELATIVE_URI option to source the creds should be in the standard credential provider chain and the above work around should not be required.

Having this said I am not asking at all that you spend more time on this, you have already done a great job by allowing us to use your tool. Thank you!

from s3deploy.