-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SharedIniFileCredentials/AWS_STS_REGIONAL_ENDPOINTS=regional fails if there's no '[default]' profile #3418
Comments
Isn't the solution to change this: aws-sdk-js/lib/credentials/shared_ini_file_credentials.js Lines 219 to 222 in f1c689f
To read: var sts = new STS({
region: roleProfile['region'],
credentials: sourceCredentials,
httpOptions: this.httpOptions
}); |
Oh, what I proposed won't actually work because of this piece of code: Lines 969 to 974 in 5ae5a7d
Given:
The "config" profile will be completely overwritten (not merged) by the credentials profile and the end result will be:
So Is this on purpose? |
This works around a bug in the AWS SDK for JS that only surfaced when we switched to `AWS_STS_REGIONAL_ENDPOINTS=regional`, requiring a `[default]` profile with a region for all users. The bug was that the INI-file AssumeRole provider would ignore the region in the profile, and always fall back to the region in: * The profile specified using `$AWS_PROFILE` (which we don't use). * Otherwise the region in the `[default]` profile (which a user may or may not have). Traditionally it didn't really matter whether the STS client got a region or not because it would always connect to `us-east-1` no matter what, but when we switched to `AWS_STS_REGIONAL_ENDPOINTS=regional`, it became illegal to not have a region. Fix the upstream bug by basically replicating the important parts of `SharedIniFileCredentials` of the AWS SDK in our codebase and patching the bug. Reported upstreeam as aws/aws-sdk-js#3418
This works around a bug in the AWS SDK for JS that only surfaced when we switched to `AWS_STS_REGIONAL_ENDPOINTS=regional`, requiring a `[default]` profile with a region for all users. The bug was that the INI-file AssumeRole provider would ignore the region in the profile, and always fall back to the region in: * The profile specified using `$AWS_PROFILE` (which we don't use). * Otherwise the region in the `[default]` profile (which a user may or may not have). Traditionally it didn't really matter whether the STS client got a region or not because it would always connect to `us-east-1` no matter what, but when we switched to `AWS_STS_REGIONAL_ENDPOINTS=regional`, it became illegal to not have a region. Fix the upstream bug by basically replicating the important parts of `SharedIniFileCredentials` of the AWS SDK in our codebase and patching the bug. Reported upstreeam as aws/aws-sdk-js#3418 Fixes #9937 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the bug
When using
SharedIniFileCredentials
with:AWS_PROFILE
).Then the credential retrieval fails if there's not a
[default]
profile with a region (even if both profiles involved in the AssumeRole operation do have aregion
in them). I'm assuming if there is a[default]
profile then the provider will use the wrong region--I did not try to confirm that.The problem does not appear when I configure
AWS_PROFILE
which makes me think there's some code that's forgetting to pass on theprofile
constructor argument to the right object.Is the issue in the browser/Node.js?
Node.js
If on Node.js, are you running this on AWS Lambda?
No
Details of the browser/Node.js version
v12.12.0
SDK version number
2.713.0
To Reproduce (observed behavior)
The following code:
Fails when given the following config:
The error is the following:
And succeeds when the following is added to
~/.aws/config
:Expected behavior
I would have expected the region from the
huijbers-admin-role
profile to be used.Additional context
Originally reported in aws/aws-cdk#9937
The text was updated successfully, but these errors were encountered: