Use STS regional endpoints for STS calls from resource providers

[willyg302]

Describe the feature

Per the STS docs:

Session tokens from Regional AWS STS endpoints are valid in all AWS Regions. Session tokens from the global STS endpoint are valid only in AWS Regions that are enabled by default.

Use Case

When attempting to use CrossAccountZoneDelegationRecord, we discovered that the cross-account assume role did not work from an opt-in region, failing with:

Received response status [FAILED] from custom resource. Message returned: AccessDenied: User: <provider Lambda execution role> is not authorized to perform: sts:AssumeRole on resource: <delegationRole>

In our case, this was due to our use of a global service principal in the delegation role's trust policy, and opt-in accounts are not visible in such a service principal. One possible workaround is to add either regional service principals or opt-in account IDs directly to the trust policy, but this is not desirable as it requires updating the delegation role for each new opt-in region.

Proposed Solution

This can be done by updating the following:

• Where instantiating an STS client directly, e.g. here, switch to new STS({ stsRegionalEndpoints: 'regional' })
• Where using chainable temporary credentials, e.g. here, switch to new AWS.ChainableTemporaryCredentials({ params, stsConfig: { stsRegionalEndpoints: 'regional' } })

Other Information

I would submit a PR myself, but am unclear on whether there are any downsides to defaulting to the regional endpoints (i.e. whether these changes can be hardcoded or should be behind a flag). At least in our team's experience, switching to the regional endpoints has caused no issues.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

v1

Environment details (OS name and version, etc.)

N/A

[peterwoodworth]

Thanks for the request @willyg302!

I would submit a PR myself, but am unclear on whether there are any downsides to defaulting to the regional endpoints

I'm also unclear on this myself, maybe someone else on the team would know. @TheRealAmazonKendra this may be interesting to you

Though, I don't see why we wouldn't at the least be able to include an option for this that isn't enabled by default

[mtrspringer]

@peterwoodworth I believe the absence of this optional also prevents the custom resource from being used in private subnets that rely on an AWS Interface Endpoint for STS access, since the InterfaceVpcEndpointAwsService class creates a regional endpoint.

The EKS cluster resource provider has regional STS endpoints enabled by default via the AWS_STS_REGIONAL_ENDPOINTS environment variable: link.

A simple solution to enable STS regional endpoints without touching the existing handler code would be to make the function environment configurable via a new AwsCustomResourceProps option: functionEnvironment?: { [string]: string }.

[rix0rrr]

I took your fix. Thanks!

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.