fix: enable sharedConfigState in AWS auth provider

[Kevintjeb]

Explanation

The value session.SharedConfigDisable prevented the AWS SDK to use the default provider chain. By removing this value from the getAWSSession function the default SDK provider chain is used. This enables the SDK to use the shared config file:
https://github.com/aws/aws-sdk-go/blob/main/aws/session/env_config.go#L84 as well as the shared credentials file:
https://github.com/aws/aws-sdk-go/blob/main/aws/session/env_config.go#L76

This fixes the code to be correct with the documentation of NewGeneratorSession which notes that it uses the authentication order:

1. service-account token.
2. static credentials.
3. sdk default provider.

See also the AWS documentation:
https://github.com/aws/aws-sdk-go/blob/main/aws/session/session.go#L158

I'm not sure why this was included initially. I've gone through the git history, but couldn't find an answer. My current guess is that the field was set due to a copy-paste error, as it is needed for the service-account authentication flow, which uses a very similar code flow.

Problem Statement

The AWS auth provider does not support the default auth provider chain due to session.SharedConfigDisable being configured.

While testing the External Secrets Operator I noticed that the default AWS SDK auth provider chain is not used, even though it's documented that it should fall back to that. I could not authenticate with the default ~/.aws/config file.

Related Issue

N/A

Proposed Changes

By not setting session.SharedConfigDisable the behaviour of using the default AWS SDK auth provider chain is restored.

Checklist

• I have read the contribution guidelines
• All commits are signed with git commit --signoff
• My changes have reasonable test coverage
• All tests pass with make test
• I ensured my PR is ready for review with make reviewable

[paul-the-alien]

Greetings!
Thank you for contributing to this project!
If this is your first time contributing, please make
sure to read the Developer and Contributing Process guides.
Please also mind and follow our Code of Conduct.

Useful commands:

• make fmt: Formats the code
• make check-diff: Ensures the branch is clean
• make reviewable: Ensures a PR is ready for review

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[moolen]

The default credential provider chain is used, only the AWS_SDK_LOAD_CONFIG (docs) mechanic has been explicitly disabled to prevent users from using it. The initial idea was to force people into using IRSA/IMDS/ENV vars etc. Looking at it now i think its safe to go with the default.

Out of curiosity: why do you need it though? Do you plan on mounting a ~/.aws/config into ESO? 🤔

[moolen]

/ok-to-test sha=a24ee45

[moolen]

/ok-to-test-managed provider=aws sha=a24ee45

[moolen]

Hey @Kevintjeb, thank you for this, change LGTM! Unless @gusfcarvalho has objections i'd be fine to merge this.

[Kevintjeb]

Thanks for the quick review and comments! The explanation makes sense. Unfortunate for us as we ‘played into’ the AWS SDK ‘default’ behaviour to support our managed auth infrastructure.

I’ve checked the source again, and you’re correct. The default flow is used, but only the config file is ignored due to the forced disable setting.

I checked the V2 of the AWS SDK and I believe that there it is the default behaviour to ‘always’ load the default path to the config file. I got confused and mixed up the differences in behaviour when issuing this PR. I generally only use the V2 SDK..

I believe we can assert that if this PR lands the current behaviour does not change. Users must still set the environment variable to indicate to the AWS SDK V1 to load the actual config file. That is also what we do to make that work. This is not needed with the V2 SDK.

Regarding your question: yes! That’s exactly what we do. It’s a ‘credential provider’ admission webhook within our clusters.