Support for regional STS endpoints in the RDS Signer

[reecefenwick]

Describe the feature

We are using the RDS signer https://github.com/aws/aws-sdk-js-v3/blob/main/packages/rds-signer/src/Signer.ts to generate credentials to connect to our RDS instances.

We already pass in a region, e.g. ap-southeast-2 and assumed tokens would be fetched from STS in that region.

As it turns out, it's going to us-east-1

It would be great if we could specify the sts endpoint to be used, or have it default to the region the database is in.

Use Case

We see significant latency when fetching tokens (2 seconds), using a regional endpoint would cut this down significantly and presumably be more reliable.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• [X] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

SDK version used

3.100.0

Environment details (OS name and version, etc.)

Alpine Linux

[mupperton]

Also suffering from this

I believe this is caused when no credentials are provided to the Signer configuration, it falls back to using fromNodeProviderChain in @aws-sdk/credential-providers, but does so without providing any configuration, so STS defaults to using us-east-1 for the AssumeRole command

Fallback code: https://github.com/aws/aws-sdk-js-v3/blob/main/packages/rds-signer/src/runtimeConfig.ts#L15

Defaulting to US region: https://github.com/aws/aws-sdk-js-v3/blob/main/clients/client-sts/src/defaultStsRoleAssumers.ts#L19

Possible solution to packages/rds-signer/src/runtimeConfig.ts:

export const getRuntimeConfig = (config: SignerConfig) => {
  return {
    runtime: "node",
    sha256: config?.sha256 ?? Hash.bind(null, "sha256"),
    credentials: config?.credentials ?? fromNodeProviderChain({ clientConfig: config?.clientConfig }),
    region: config?.region ?? loadConfig(NODE_REGION_CONFIG_OPTIONS, NODE_REGION_CONFIG_FILE_OPTIONS),
    ...config,
  };
};

The trick being providing the clientConfig option to fromNodeProviderChain which is then passed down to the STS constructor

Usage:

const signer = new Signer({
  region: 'ap-southeast-2',
  clientConfig: {
    region: 'ap-southeast-2',
  },
});

Reference: https://github.com/aws/aws-sdk-js-v3/blob/main/packages/credential-providers/src/fromNodeProviderChain.ts#L38

@RanVaknin - Please advise

Edit:

Could extend to support clientPlugins too if desired which packages/credential-providers/src/fromNodeProviderChain.ts passes if provided

[mupperton]

For now my workaround is

import { fromNodeProviderChain } from '@aws-sdk/credential-providers'
import { Signer } from '@aws-sdk/rds-signer'

const region = process.env.AWS_REGION ?? 'eu-west-1'

const signer = new Signer({
  region,
  credentials: fromNodeProviderChain({ clientConfig: { region } }),
})

[aBurmeseDev]

Hi all - checking in here.

What's shown in previous comment is actually the correct way to set the region. If this's still a valid FR, please provide more use cases for the team to further discuss.

[reecefenwick]

Maybe I'm wrong here but it feels inconsistent with the rest of the AWS SDKs, this is the only one where I've had the surprise of my application going across the world to get a token 😁

What's the rationale behind going to us-east-1 by default for STS and not using the region provided to the Signer?

[mhamann]

This should definitely be classified as a bug.

We're using the RDS signer in EKS. Every other AWS SDK service that we've used grabs our IRSA token mounted in the container and then authenticates with the correct regional STS endpoint.

We wasted hours trying to figure out why the RDS signer was telling us our OIDC provider couldn't be found in the account only to realize it was defaulting to us-east-1, when the EKS cluster is in us-gov-west-1. Since those two don't connect, it's a total failure scenario.

The behavior needs to be changed to match that of the rest of the AWS SDK.