Remove credentials provider settings #45
Conversation
Remove credentials provider settings to allow the AWS go SDK to pull credentials from Instance Profile/Metadata.
|
This issue hit us as well. So either this change, or a flag to disable this behaviour |
|
This definitely makes sense. AWS creds were used improperly from the beginning. And one day we need to turn to conventional use. But won't this break something to existing users? AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY will go on working as expected? Also, I don't see any value in commenting code instead of deleting it. Thanks! |
|
The way the Go AWS SDK (and all the other AWS SDKs work) resolve credentials is as follows (here's the actual source https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html):
So ENV variables (AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) will always take precedence. AWS_REGION will control the region and AWS_PROFILE will select a profile from your .aws credentails. So this shouldn't break anything. |
Totally fair. I'll update the PR. Also, to add to what @andersosthus has already said, it may be that prior versions of the aws go sdk didn't work as the other aws sdks did, so the code that was forked from the original storages may have been required at some point in the past. That's speculation on my part, though. Currently the aws go sdk, if given a blank credential provider configuration, will search the four places listed above automatically with no need for additional configuration. So it shouldn't break anything =) |
Per wal-g#45 (comment), remove the code rather than comment it out.
|
Thanks! |
Have you tried it? When I updated main WAL-G with this pr, |
After merging wal-g/storages#45 we are unable to configure multiple s3 storages as it needed in copy commands. Suggested fix wal-g#1050 works, but it's dirty. Call to the `FolderFromConfig` pollutes the environment, making impposible to any configuration function (like `ConfigureCompressor`) after it. Solution: * Wal-g config file should be the first priorty configuration source. * Set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY only if they are not empty, otherwise fallback to the enviroment (and other storage dependent) configuration defaults * Do not overwrite the environment in `FolderFromConfig`
After merging wal-g/storages#45 we are unable to configure multiple s3 storages as it needed in copy commands. Suggested fix wal-g#1050 works, but it's dirty. Call to the `FolderFromConfig` pollutes the environment, making impposible to any configuration function (like `ConfigureCompressor`) after it. Solution: * Wal-g config file should be the first priorty configuration source. * Set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY only if they are not empty, otherwise fallback to the enviroment (and other storage dependent) configuration defaults * Do not overwrite the environment in `FolderFromConfig`
Remove credentials provider settings to allow the AWS go SDK to pull credentials from Instance Profile/Metadata.
This is similar to PR #15, but involves just commenting out the credentials provider section so the AWS go SDK can do it's thing.
Resolves the issues I am having with wal-g hanging on an instance with no .aws/credentials or similar.