[Bug]: AWS Provider fails with opt-in regions and assume role configuration

[malachi-constant]

Terraform Core Version

1.5.3

AWS Provider Version

v4.57.0

Affected Resource(s)

provider "aws" {}

Expected Behavior

AWS role should be allowed to be assumed in an opt-in region even if the identity (assuming account) does not have the opt-in region enabled.

Actual Behavior

This configuration works when Identity's account has the same opt-in region enabled. It does not when the region is only enabled in the account the assumed role resides in.

provider "aws" {
  region = "ap-south-2"
  assume_role {
    role_arn     = "arn:aws:iam::111111111111:role/LayerManagement"
    session_name = "GitlabLayer"
  }
}

Relevant Error/Panic Output Snippet

AWS Error: operation error STS: AssumeRole, https response error StatusCode: 403, RequestID: 59fbba66-d74e-4d74-9ffb-bd9940ccadd3, api error InvalidClientTokenId: The security token included in the request is invalid

Terraform Configuration Files

provider "aws" {
  region = "ap-south-2" # Opt-in Region
  assume_role {
    role_arn     = "arn:aws:iam::111111111111:role/LayerManagement" # Account B Assumable Role
    session_name = "GitlabLayer"
  }
}

Steps to Reproduce

1. Account A Identity not opted-in to any regions
2. Account B With an assumable role and an opt-in region.

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[cervantn]

Just adding some additional context here:

In IAM, you can update an AWS account to return session tokens from STS' global endpoint which will work in any region, including opt-in regions, by calling SetSecurityTokenServicePreferences and upgrading to using v2Tokens (see the Managing global endpoint session tokens AWS docs).

This, in turn, allows an AWS account which is not opted-in to a given region to assume a role into an account which is opted-in to that region using the global STS endpoint. The global endpoint must be used if the source account is not opted-in to the given region, as it won't be permitted to call the regionalized STS endpoint.

If you want to check if an AWS account is opted-in to a given region, you can do so by calling the ListRegions API.