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

Specify that S3 signature validation needs the accesskey/secretkey to be set to test #1186

Merged
merged 3 commits into from
May 2, 2024

Conversation

krishanbhasin-px
Copy link
Contributor

@krishanbhasin-px krishanbhasin-px commented Apr 22, 2024

I've been setting up my localstack S3 and couldn't get the signature validation passing.

I came across this comment which indicated I needed to set my access key/secret key to the specific value of test in order to make this work; this PR adds that note to the configuration information for S3.

I had been trying to use a structured S3 key, like referenced in the docs

I had thought this might be related to me running the s3-latest docker image which presumably doesn't include STS, but swapping to the full image doesn't seem to fix it, even when specifying SERVICES=s3,sts

Copy link

github-actions bot commented Apr 22, 2024

🎊 PR Preview has been successfully built and deployed to https://localstack-docs-preview-pr-1186.surge.sh 🎊

Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @krishanbhasin-px and thanks for your contribution!

I can add a bit more context to it:

If using the regular LocalStack image, you can use the pre-signed URL validation with a created role and getting the credentials for the role, and this will work.

However, for simplicity purpose, LocalStack treats unrecognized AWS Access Keys as the default root account (000000000000), and the Secret Access Key is only used for signing purpose.

However, when sending a request to LocalStack with random credentials, LocalStack cannot know what your secret key is. In order to be able to validate the signature, we need to make sure that the secret key used in the client and the "server" (here LocalStack) are the same. This is why the test value is hardcoded as a fallback. You can read this PR description to understand a bit more what is happening under the hood: localstack/localstack#10265

This was just to give more context 😄 thanks for adding this, we will also add a note in the S3 page directly to explain a bit more why the Secret Key need to be set. With the linked PR, you now only have to set the Secret Access Key to test in order for the validation to be successful, the Access Key Id used will be the one of the request.

Thanks again for the contribution and sorry for the initial issue!

content/en/references/configuration.md Outdated Show resolved Hide resolved
Co-authored-by: Ben Simon Hartung <42031100+bentsku@users.noreply.github.com>
@krishanbhasin-px
Copy link
Contributor Author

Hey @bentsku that makes much more sense to me now, thank you for taking the time to write such a detailed response.
And thank you for localstack, it's so useful!

Copy link
Contributor

@bentsku bentsku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@krishanbhasin-px thank you again for the contribution and raising this issue, I'm sorry again it wasn't very clear.

Also, sorry in the delay in reviewing 😕

I'll open a PR soon trying to condense the previous response into the S3 documentation as well.
Welcome to the contributors!

@bentsku bentsku merged commit 1aae395 into localstack:main May 2, 2024
3 checks passed
@krishanbhasin-px krishanbhasin-px deleted the patch-1 branch May 2, 2024 16:25
@rpgdev
Copy link

rpgdev commented Aug 6, 2024

@krishanbhasin-px why doesn't the configuration page also makes it explicit that this setting affects the timeout for signed urls? Makes it impossible to find out from just ctrl+f the configuration page.

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

Successfully merging this pull request may close these issues.

3 participants