fix: use controller's base region for CARM STS AssumeRole calls#228
fix: use controller's base region for CARM STS AssumeRole calls#228michaelhtm wants to merge 2 commits intoaws-controllers-k8s:mainfrom
Conversation
When a resource targets a different region than the controller's home region, the STS AssumeRole call was incorrectly using the target region's STS endpoint. This fails when the target is an opt-in region whose STS endpoint cannot process AssumeRole for the base region's credentials. With this change, AssumeRole calls are made using the base region's STS endpoint, and the returned config is then set to the desired target region for resource management
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: michaelhtm The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@michaelhtm: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
knottnt
left a comment
There was a problem hiding this comment.
@michaelhtm Just a minor nit on the actual code change, but I think we'll also need to add a test validate this fix.
| baseRegion ackv1alpha1.AWSRegion, | ||
| region ackv1alpha1.AWSRegion, |
There was a problem hiding this comment.
nit: Without additional knowledge it isn't totally clear what the baseRegion and region parameters actually mean. Could you add a description for the function that defines these parameters? Also renaming the parameters to something like defaultControllerRegion and targetRegion/resourceRegion could help.
There was a problem hiding this comment.
An explanation of why both values are needed would also be helpful.
Description of changes:
When a resource targets a different region than the controller's home
region, the STS AssumeRole call was incorrectly using the target
region's STS endpoint. This fails when the target is an opt-in region
whose STS endpoint cannot process AssumeRole for the base region's
credentials. With this change, AssumeRole calls are made using the
base region's STS endpoint, and the returned config is then set to the
desired target region for resource management
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.