Assuming role configured in AWS profile does not work outside of aws partition (China, US Gov Cloud, etc.) #6711
Comments
csy97
added
bug
|
When I modify the code to the following it is working My confusion is that even if I specify the region in the .config and credentials files it doesn't seem to take effect whether fromIni can read . /aws/config? [root@ip-172-31-22-83 nodejs]# cat a.js
const { fromIni } = require("@aws-sdk/credential-providers");
const { STSClient, GetCallerIdentityCommand } = require("@aws-sdk/client-sts");
async function getRoleIdentity() {
const credentials = fromIni({
profile: "tes_assume",
clientConfig: { region: "cn-north-1" }
});
console.log(`credentials:`, credentials);
const stsClient = new STSClient({
endpoint: "https://sts.cn-north-1.amazonaws.com.cn",
credentials,
region: "cn-north-1",
});
try {
// 调用 GetCallerIdentity API
const command = new GetCallerIdentityCommand({});
const response = await stsClient.send(command);
console.log("Current Role Identity:");
console.log(`response:`, response);
console.log(`Account: ${response.Account}`);
console.log(`UserId: ${response.UserId}`);
console.log(`ARN: ${response.Arn}`);
} catch (error) {
console.error("Error fetching identity:", error);
}
}
getRoleIdentity(); |
zshzbh
added
p2
|
I can't reproduce this issue In config - In credentials Code I have import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
import { fromIni } from "@aws-sdk/credential-providers";
async function getRoleIdentity() {
const credentials = fromIni({
profile: "test",
// clientConfig: { region: "us-east-1" },
});
console.log("credentials: ", credentials);
const stsClient = new STSClient({
credentials,
region: "us-east-1",
});
try {
const command = new GetCallerIdentityCommand({});
const response = await stsClient.send(command);
console.log("Current Role Identity:");
console.log(`Account: ${response.Account}`);
console.log(`UserId: ${response.UserId}`);
console.log(`ARN: ${response.Arn}`);
} catch (error) {
console.error("Error fetching identity:", error);
}
}
getRoleIdentity();I can get the result without specifying the region. I will talk about it with the team |
|
Hey @csy97 ,
Please let me know if you have any other questions. Thanks |
zshzbh
added
response-requested
zshzbh
added
the
investigating
|
Hi @zshzbh, We do have additional questions. The It doesn't seem correct for SDKv3 to ignore the |
|
I did some research using mitmproxy to see what the different clients do, comparing the AWS CLI, SDKv2 and SDKv3. TL;DR: The CLI and SDKv2 behave the same, SDKv3 behaves differently. ConfigThe behavior depends a lot on the configuration setup. I used the following config:
ResultsThe AWS CLI (v1 and v2)For better or worse, the AWS CLI defines the Gold Standard of how these files are supposed to behave. Result, 2 calls, both to
Conclusion: the AWS CLI v2 uses the region of the target profile to determine in what region to perform the I also tested AWS CLIv1 (including The SDKv2I used the following program to test the behavior of the previous iteration of the SDK: process.env.AWS_SDK_LOAD_CONFIG = '1';
import { STS } from 'aws-sdk';
import { SharedIniFileCredentials } from 'aws-sdk';
import { ProxyAgent } from 'proxy-agent';
import * as AWS from 'aws-sdk';
async function main() {
AWS.config.update({
httpOptions: { agent: new ProxyAgent() }
});
// Load credentials from INI file
const credentials = new SharedIniFileCredentials({ profile: 'Assumable' });
// Configure STS client with proxy and credentials
const sts = new STS({
credentials: credentials,
});
const identity = await sts.getCallerIdentity().promise();
console.log('Caller Identity:', identity);
}
main().catch(e => {
console.error(e);
process.exitCode = 1;
});Command line: Result, 2 calls, one
Conclusion: the SDK v2 uses the region of the target profile to determine in what region to perform the If I pass the profile with
SDK v3Using the following program: import { STS } from '@aws-sdk/client-sts';
import { ProxyAgent } from 'proxy-agent';
import { fromNodeProviderChain } from '@aws-sdk/credential-providers';
import { NodeHttpHandler } from '@smithy/node-http-handler';
async function main() {
// Configure proxy for STS client
const clientConfig = {
requestHandler: new NodeHttpHandler({
httpsAgent: new ProxyAgent()
})
};
const stsClient = new STS({
credentials: fromNodeProviderChain({ profile: 'Assumable', clientConfig }),
...clientConfig,
});
const identity = await stsClient.getCallerIdentity();
console.log('Caller Identity:', identity);
}
main().catch(e => {
console.error(e);
process.exitCode = 1;
});Command line: Results
Conclusion: I guess again I can't fault the SDK for performing the With
At least the target region is correct, but the AssumeRole region is still wrong! ConclusionDisregarding the target region of the
One of these is not like the others... 😬 |
|
For shits and giggles, I decided to give myself an aneurism and tried to pass in different sources of region information that conflict with the profile setting, using command-line flags and environment variables, to see what would happen:
The CLIs will always let environment variables and command line switches override both regions. The CLIv1 ignores SDKv2 ignores SDKv3 ignores |
github-actions
bot
added
potential-regression
zshzbh
added
queued
|
Hey @rix0rrr, Thanks for the test! The CLI is a special case as it supports command line options. The command line options in the CLI are roughly equivalent to specifying the region in a service client instantiation, so the region specified in CLI always takes precedence. As for JS SDK V3 defaults to As for JS SDK V2, as it's maintenance mode, we only fix critical bugs and security issues. Thanks! |
|
The current search order for inner STS assume role region is:
For all SDKs, the general configuration precedence is the same: CODE, ENV, FILE, in that order. // no credentials provider is set, the default credentials provider
// will prioritize the parent client region
new Client({ region: 'us-west-2' });
// STS AssumeRole is called with us-west-2 (priority=2).The UX problem here is that when you define a custom credentials provider, import { fromIni } from "@aws-sdk/credential-providers";
const provider = fromIni({ ... });even though this is an SDK credential provider, it is a standalone function. As such, it is considered a CODE level configuration, so the region should be set on it like so: fromIni({ profile: "abc", clientConfig: { region: "..." } });If you were to instead set All that said, the behavior clearly defies the expectations of the caller, so we need to think about what can be safely changed. Initially, I would consider the following change:
|
github-actions
bot
removed
the
response-requested
|
We need to configure things like a proxy agent, do we have to configure in code. Yet I still want the region from the profile if that what is being asked for by the user |
Checkboxes for prior research
Describe the bug
When I call GetCallerIdentityCommand at cn-north-1 the request will be sent to the STS service at us-east-1. China's resources are isolated from global, so obviously this won't work in China.
Regression Issue
SDK version number
@aws-sdk/package-name@version, ...
Which JavaScript Runtime is this issue in?
Node.js
Details of the browser/Node.js/ReactNative version
v18.20.5
Reproduction Steps
credentials file like this
config file like this
The js code is very simple.When I try to execute GetCallerIdentityCommand using profile test_assume I get the error “Error fetching identity: InvalidClientTokenId: The security token included in the request is invalid”
package.json
{ "dependencies": { "@aws-sdk/client-sts": "^3.699.0", "@aws-sdk/credential-providers": "^3.699.0" } }I capture tcpdump request during cdk bootstrap command. The output is
I capture tcpdump request during cdk bootstrap command. The output is
As you can see, the ip address of STS service requested is in us-east-1 region.
Apparently, it could not work in the China region. Please fix this issue, Thanks!
Observed Behavior
Expected Behavior
SDK V3 Using source_profile works fine.
Possible Solution
No response
Additional Information/Context
No response
The text was updated successfully, but these errors were encountered: