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.

Sign up for GitHub

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

Jump to bottom

Unable to copy images to non-default regions with AssumeRole #469

Open
william00179 opened this issue Mar 19, 2024 · 3 comments · May be fixed by #479
Open

Unable to copy images to non-default regions with AssumeRole #469

william00179 opened this issue Mar 19, 2024 · 3 comments · May be fixed by #479
Labels
bug stage/needs-verification Issue needs verifying it still exists

Comments

@william00179
Copy link

Overview of the Issue

I'm able to successfully assume a role and copy images to multiple regions that are enabled by default in AWS. If I try to copy a region to a non-default region, for example Hong Kong, I will get the following error

* Error Copying AMI (ami-0d68130680fad52b4) to region (ap-east-1): AuthFailure: AWS was not able to validate the provided access credentials

It seems that Packer is calling the global STS endpoint which issues version 1 tokens which can not be used in non-default regions, see https://repost.aws/knowledge-center/iam-validate-access-credentials

Reproduction Steps

Create a configuration with AssumeRole and attempt to copy an image to a non-default region, ie one you must enable explicitly like Hong Kong (ap-east-1)

Plugin and Packer version

Latest and 1.3.1

Packer should use the regional STS endpoint to ensure version 2 tokens are used
@william00179
Copy link
Author

This can be worked around by setting the env var AWS_STS_REGIONAL_ENDPOINTS=regional

Perhaps this should be added to the documentation or set as the default as this is the default the SDKs are being moved to in their next major releases.

@lbajolet-hashicorp
Copy link
Contributor

Hi @william00179,

Thanks for reporting this!
I wasn't aware that regional STS endpoints were a thing, good to know.
I'll read some docs on that subject, and will probably open some PRs to address this however is relevant for the plugin/Packer.

Thanks again!

@lbajolet-hashicorp lbajolet-hashicorp linked a pull request Apr 24, 2024 that will close this issue
Draft
@lbajolet-hashicorp
Copy link
Contributor

lbajolet-hashicorp commented May 13, 2024 •
edited
Loading

Hey @william00179,

Did you have a chance to test the related PR I pushed?
For reference I had started to work on acceptance tests, but my scenario (build on us-east-1 and copy to eu-central-2) works with or without my patch, despite us-east-1 being a default region and eu-central-2 not being a default region, which leads me to believe I either did not understand the problem, or there's something on my account/settings that lets me do that copy for some reason.

Let me know if you need a hand regarding testing, I can probably help you with that.

Thanks!

cc: @hferreira23 since you reacted on the workaround comment, are you experiencing this issue as well? Would you be able to test a pre-release of the plugin to see if this helps in your situation?

@lbajolet-hashicorp lbajolet-hashicorp added the stage/needs-verification Issue needs verifying it still exists label Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug stage/needs-verification Issue needs verifying it still exists
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

common: use regional STS on non-default regions hashicorp/packer-plugin-amazon
2 participants
@william00179 @lbajolet-hashicorp