Skip to content
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

STSClient does not use environment variable for region controls #5105

Open
3 tasks done
nbbeeken opened this issue Aug 18, 2023 · 4 comments
Open
3 tasks done

STSClient does not use environment variable for region controls #5105

nbbeeken opened this issue Aug 18, 2023 · 4 comments
Labels
bug This issue is a bug. p2 This is a standard priority issue queued This issues is on the AWS team's backlog

Comments

@nbbeeken
Copy link

Checkboxes for prior research

Describe the bug

When invoking fromNodeProviderChain using IAM AssumeRoleWithWebIdentity I expect environment variables AWS_REGION / AWS_DEFAULT_REGION / AWS_STS_REGIONAL_ENDPOINTS to control the region that the STSClient uses to send the http request. However, it can be observed that the request is always routed to us-east-1 unless the region is programmatically set.

Documentation References:

SDK version number

@aws-sdk/credential-providers@3.391.0

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

v20.2.0

Reproduction Steps

Running the fromNodeProviderChain function with http debugging turned on, like so:

node="$(which node)"
env -i \
  NODE_DEBUG="http" \
  AWS_WEB_IDENTITY_TOKEN_FILE="..path../web_token_file" \
  AWS_ROLE_ARN="arn:aws:iam::xxxxxxxxxxxx:role/xxx" \
  AWS_STS_REGIONAL_ENDPOINTS="regional" \
  AWS_REGION="us-west-2" \
  $node -e \
  "require('@aws-sdk/credential-providers').fromNodeProviderChain()().then(() => console.log('success'), e => console.log('error', e))"

Observed Behavior

Logs

HTTP 30987: createConnection sts.us-east-1.amazonaws.com:443

to the terminal, indicating the region variable and the sts_regional_endpoints are not having the desired effect.

Expected Behavior

The AWS_REGION variable along with the AWS_STS_REGIONAL_ENDPOINTS setting should have made the API call contact sts.us-west-2.amazonaws.com:443

Possible Solution

No response

Additional Information/Context

No response

@nbbeeken nbbeeken added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Aug 18, 2023
@yenfryherrerafeliz yenfryherrerafeliz self-assigned this Aug 21, 2023
@yenfryherrerafeliz yenfryherrerafeliz added investigating Issue is being investigated and/or work is in progress to resolve the issue. and removed needs-triage This issue or PR still needs to be triaged. labels Aug 28, 2023
@yenfryherrerafeliz
Copy link
Contributor

Hi @nbbeeken, I can confirm that the default STS client, used internally to resolve credentials with web identity token, does not consider the AWS_DEFAULT_REGION variable to populate the region, instead it considers just either a region passed as parameter or the default one which is us-east-1. This can be confirmed in the following implementation here. However, I need to discuss with the team regarding if this is the expected behavior or not. As workaround, you have the option to explicitly provide the region you want the STS client to use, as follow:

import {ListBucketsCommand, S3Client} from "@aws-sdk/client-s3";
import {fromNodeProviderChain} from "@aws-sdk/credential-providers";

const credProvider = fromNodeProviderChain({
    clientConfig: {
        region: "YOUR-DESIRED-STS-REGION"
    }
});
const client = new S3Client({
    region: "us-east-2",
    credentials: credProvider
})
const response = await client.send(new ListBucketsCommand({}));

console.log(response)

Please let me know if that helps!

Thanks!

@yenfryherrerafeliz yenfryherrerafeliz added response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. needs-review This issue/pr needs review from an internal developer. p2 This is a standard priority issue and removed investigating Issue is being investigated and/or work is in progress to resolve the issue. labels Aug 30, 2023
@nbbeeken
Copy link
Author

Thank you for looking into this @yenfryherrerafeliz! As a library author providing direct control over these options means adding more knobs to our public API (ex. a pass-through object for users to provide their own options). It would be nice to avoid the need for bespoke controls like this when the docs point to these environment variables as the proper controls.

Thanks for the code sample, good to know I am on the right track with the workaround! You can see mongodb/node-mongodb-native#3831 we have translated the environment variables to options in the MongoDB driver since we need this to apply to existing versions of the SDK.

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to \"closing-soon\" in 7 days. label Aug 31, 2023
@gabegorelick
Copy link

This is definitely surprising behavior. At the very least, this needs to be documented. From what I can tell, it's not documented anywhere.

@swcm-mnestler
Copy link

I would go a step further and say that this is documented as "supported", and the fact that it does not work is a bug. Please at least update the documentation to reflect the actual behavior

@yenfryherrerafeliz yenfryherrerafeliz added queued This issues is on the AWS team's backlog and removed needs-review This issue/pr needs review from an internal developer. labels Oct 24, 2023
@yenfryherrerafeliz yenfryherrerafeliz removed their assignment Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. p2 This is a standard priority issue queued This issues is on the AWS team's backlog
Projects
None yet
Development

No branches or pull requests

4 participants