Open william00179 opened 8 months ago
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.
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!
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?
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
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