fix(server): use regional STS endpoint for aws-iam credentials verification#6130
fix(server): use regional STS endpoint for aws-iam credentials verification#6130Ashut0sh-mishra wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: bebdee4d40
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| } | ||
|
|
||
| const payloadHash = crypto.createHash('sha256').update('').digest('hex'); |
There was a problem hiding this comment.
Remove duplicated signer block
In every environment loading this hook, the duplicated block starts after getAWSAuthHeader has already closed, so these statements are at module scope; the top-level return later in this block and references to locals like host/date make the TypeScript build fail before AWS IAM verification can run. Removing the stray duplicate block restores the module.
Useful? React with 👍 / 👎.
…cation The aws-iam Connect UI verifier previously called sts:GetCallerIdentity against the legacy global STS host sts.amazonaws.com while signing the SigV4 request with the user-entered region. The global STS endpoint only accepts signatures whose credential scope is us-east-1, so any other region produced SignatureDoesNotMatch, which the verifier's catch block masked as "Invalid AWS credentials or permissions." Users with valid keys saw "AWS IAM did not validate your credentials" whenever they picked, e.g., us-west-2. Switch the verifier to the regional STS endpoint sts.<region>.amazonaws.com (and sts.<region>.amazonaws.com.cn for China partition regions) and keep the user region in the SigV4 scope. This: - Fixes the false-negative for every non-us-east-1 commercial region. - Enables AWS GovCloud regions (us-gov-west-1, us-gov-east-1). - Enables AWS China regions (cn-north-1, cn-northwest-1). The actual proxy template in providers.yaml still hits the global IAM endpoint, which is correct - IAM is genuinely global, but STS is regionalised. These are two different services, now signed consistently. Plumbs host through AWSAuthHeaderParams so the canonical request, the Host header, and the baseUrlOverride all agree. Closes NangoHQ#6048 Co-authored-by: nik464 <nikhil18chaudhary@gmail.com>
bebdee4 to
f49b4dd
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f49b4dd820
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (region.startsWith('cn-')) { | ||
| return `sts.${region}.amazonaws.com.cn`; | ||
| } | ||
| return `sts.${region}.amazonaws.com`; |
There was a problem hiding this comment.
Reject unsupported partitions during verification
When an aws-iam connection uses a cn-* or us-gov-* region, this helper now lets GetCallerIdentity succeed against partition-specific STS, but the provider still sends actual IAM calls to https://iam.amazonaws.com and signs them with us-east-1 in packages/providers/providers.yaml lines 2113-2115. AWS' IAM endpoint table lists GovCloud IAM under iam.us-gov.amazonaws.com (https://docs.aws.amazon.com/general/latest/gr/iam-service.html), so Connect can now accept credentials for partitions whose subsequent IAM actions are sent to the wrong host/signing scope. Either keep verification restricted to partitions supported by the proxy template or update the proxy host/signing for those regions.
Useful? React with 👍 / 👎.
What
Fixes
aws-iamcredentials verification when the user picks any region other thanus-east-1in the Connect UI.Root cause
packages/server/lib/hooks/connection/providers/aws-iam/credentials-verification.tscallssts:GetCallerIdentityagainst the global STS host (sts.amazonaws.com) but signs the SigV4 request withconnection_config.region. The global endpoint only accepts signatures whose credential scope isus-east-1, so any other region producesSignatureDoesNotMatch. The verifier'scatchblock swallows the AWS error and rethrows the genericInvalid AWS credentials or permissions., which surfaces in the UI as "AWS IAM did not validate your credentials" despite valid keys.Confirmed in the issue by
aws sts get-caller-identitysucceeding from a CLI in the same region against the regional endpoint, plus manually signing againststs.amazonaws.comwith non-us-east-1scope reproducing the same error.Fix
Switched to the regional STS endpoint
sts.<region>.amazonaws.com(Option B in the issue) and kept the user-entered region in the SigV4 scope. Added a smallgetStsHost(region)helper that:sts.<region>.amazonaws.comfor standard commercial regions.sts.<region>.amazonaws.com.cnfor China partitions (cn-north-1,cn-northwest-1).us-gov-west-1,us-gov-east-1), where the standard.amazonaws.comsuffix is correct.Plumbed
hostthroughAWSAuthHeaderParamsso the canonical request, theHostheader, and thebaseUrlOverrideall line up.The
providers.yamlaws-iamproxy template still hits the globaliam.amazonaws.comendpoint signed withus-east-1- that is intentionally correct because IAM is a genuinely global service, while STS is regionalised. These are two different services and the verifier was the only place where they were conflated.Changes
packages/server/lib/hooks/connection/providers/aws-iam/credentials-verification.ts: derive host from region, pass it into the signer, use it asbaseUrlOverride.packages/server/lib/hooks/connection/providers/aws-iam/types.ts: addhost: stringtoAWSAuthHeaderParams.Testing
host:sts.<region>.amazonaws.com, the network call goes to the matching host, andcredentialScopecontinues to use the same<region>, so the AWS-side scope check passes for the same region the user selected. Forus-east-1callers nothing observable changes (the regional and global endpoints both accept us-east-1 scope).Closes #6048
Co-authored-by: nik464 <nikhil18chaudhary@gmail.com>