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

Account for STS no longer being a single region service #166

Closed
ryanblock opened this issue May 28, 2024 · 3 comments
Closed

Account for STS no longer being a single region service #166

ryanblock opened this issue May 28, 2024 · 3 comments

Comments

@ryanblock
Copy link
Contributor

Code in question: https://github.com/mhart/aws4/blob/master/aws4.js#L111

Per AWS: AWS recommends using Regional AWS STS endpoints instead of the global endpoint to reduce latency, build in redundancy, and increase session token validity.

Today, when you pass a region in a request to aws4, the signature specifies the passed region (e.g. 'AWS4-HMAC-SHA256 Credential=.../20240528/us-west-2/sts/aws4_request...), however the request always goes to sts.amazonaws.com, and not sts.$region.amazonaws.com, resulting in a 403 / SignatureDoesNotMatch error.

It appears that by default all STS regions are enabled and active by default since late 2015, witha manual opt-out (ref), so my expectation would be this should be a fairly safe change to make.

Happy to PR, as ever, if so desired!

@ryanblock ryanblock changed the title Update signing to account for STS no longer being a single region service Account for STS no longer being a single region service May 28, 2024
@ryanblock
Copy link
Contributor Author

Update: just found #162

@mhart
Copy link
Owner

mhart commented May 28, 2024

Yeah, so just repeating the instructions there:

aws4.sign({ host: 'sts.us-west-2.amazonaws.com', path: '/?Action=AssumeRole' })

The backwards-compat cases will be if someone's using a non-us-east-1 region currently (potentially unwittingly – perhaps it's in a general config object) – then any calls would currently be going to sts.amazonaws.com and that would suddenly change.

In most cases you'd hope that change is beneficial! But as we all know, you can't predict how it might affect ppl.

If this is related to aws-lite and you're happy with assuming they want to use the regional endpoints (pretty safe assumption for a newer library), I think just be explicit and use hostnames. You should be able to use "region" and "service" as well as "host" if you'd like to be extra sure everything's going to sign ok. TBH in general being more explicit is always going to be what you want – otherwise you're relying on aws4 to do the guessing for you, and it might just get behind the times.

@mhart
Copy link
Owner

mhart commented May 28, 2024

Just in case you hadn't seen it (though I'm sure you have), aws4 will only call the "guessing" code path if you don't pass in a host:

aws4/aws4.js

Lines 64 to 65 in 51d3a2f

if (!headers.Host && !headers.host) {
headers.Host = request.hostname || request.host || this.createHost()

Same with service and region:

aws4/aws4.js

Lines 55 to 56 in 51d3a2f

this.service = request.service || hostParts[0] || ''
this.region = request.region || hostParts[1] || 'us-east-1'

So ultimately you've got the most control if you specify all three.

Going to close this, but can keep in mind for a 2.x if such a thing is ever wanted/needed.

@mhart mhart closed this as completed May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants