AwsCustomResource: AssumeRole call now fails in non-opted-in region after issue #26562 was addressed

[tjdasso]

Describe the bug

For the AwsCustomResource construct, we are now seeing issues with our existing stack after issue #26562 was addressed. Our stack assumed that the AssumeRole call would be made in the stack region, instead of the AwsSdkCall region, which caused issues as the stack account is not opted into the region where the AWS call is being made (but the assumed account is).

For example: account 1 is deploying a stack to region A where account 1 is opted in. The stack contains an AwsCustomResource construct which assumes a role in account 2, and makes an AWS call to region B (where account 2 is opted in, but account 1 is not). The previous functionality would make the AssumeRole call in region A, where both accounts are opted in, and then use the returned account 2 credentials to make the AWS call in region B (where account 2 is opted in). With the updated functionality, the AssumeRole call is made directly to region B, where account 1 is not opted in, and thus the call to STS is denied and the AwsCustomResource deployment fails.

Expected Behavior

We expected the AssumeRole call to be made in the stack region, as was the previous functionality before issue #26562 was addressed.

Current Behavior

Issue #26562 updated the default functionality to change the region where the AssumeRole call is made, which causes issues when the stack account is not opted into the region where the AWS call is being made. (This should only be an issue when the AssumeRole call is assuming a role in a different account.)

Stack deployments fail with the following resource error in CloudFormation:

Received response status [FAILED] from custom resource. Message returned: The security token included in the request is invalid (RequestId: ...)

Reproduction Steps

Create an AwsCustomResource that assumes a role in a different account. If the AwsCustomResource region points to a region that is not opted-in by the stack account but is opted-in by the assumed account, the call fails with an invalid security token error.

Possible Solution

Add a new optional parameter that defines what region the AssumeRole call will be made. Issue #26562 seems to be addressing a valid use case; however, there are also use cases where the AssumeRole call needs to be made in a different region. Having a configurable region parameter for both the AssumeRole call and the main AWS call provides additional flexibility for both use cases.

Additional Information/Context

Issue potentially introducing backwards-incompatible functionality: #26562
Suspected commit: 3701aa7
CDK release with suspected commit: https://github.com/aws/aws-cdk/releases/tag/v2.94.0

CDK CLI Version

2.94.0 (and up)

Framework Version

No response

Node.js Version

18

OS

AL2

Language

TypeScript

Language Version

No response

Other information

No response

[pahud]

Thank you. We will look into this.

[scanlonp]

@tjdasso, thanks for opening this PR! Fixing non-opt-in stack -> opt-in stack looks like it broke opt-in stack -> non-opt-in stack. We will need to find a way to let the user indicate which case they are in to enable the assume role call and the additional sdk call to both be successful.