TargetGroupBindings can now manipulate target groups from different aws accounts

[marcosdiez]

Issue #3634

Description

Now, every time a TargetGroupBinding has the alb.ingress.kubernetes.io/IamRoleArnToAssume (and optionally alb.ingress.kubernetes.io/AssumeRoleExternalId) annotations, we assume it before interacting to it (actually, the assume role operation is cached).

In real life, I changed:

• targetgroupbinding_validator
• targetgroupbinding_mutator
• target manager (which has RegisterTargets / DeregisterTargets / ListTargets

This way we can easily manipulate target groups from target group bindings for every single AWS account in the world, as long as there is a role we can assume. In order to prevent the confused deputy problem, external id is supported.

The way this was implemented was actually way simpler than initially imagined:

the service.elbv2Client object now supports a new method called AssumeRole which returns service.elbv2Client on the specified role. The catch is that if AssumeRole is called with a blank role, the object returns itself and life goes on.

In other words, every time we call some method from elbv2Client from something related to target groups, we also call AssumeRole and that's basically it.

Caching the assumed role was also trivial, a simple map that is stored on cloud.go

I decided to have cloud.go manage the caching becuase in the future it could assume role for other objects if needed and all the assume role logic would be in the same place.

The only unfortunate change that needed to be made is that aws.Cloud became services.Cloud else golang would complain about circular dependency :(

This is what the logs look like:

{"level":"info","ts":"2024-05-13T03:24:31Z","msg":"awsCloud","method":"GetAssumedRoleELBV2","AssumeRoleArn":"arn:aws:iam::7550XXXXXXXX:role/alb-controller-policy-to-impersonate","externalId":"XXXXXX"}
{"level":"info","ts":"2024-05-13T03:24:33Z","msg":"registering endpoints using the targetGroup's vpcID vpc-00XXXXXXXXXXXXXXX which is different from the cluster's vpcID vpc-04XXXXXXXXXXXXXXX"}
{"level":"info","ts":"2024-05-13T03:24:33Z","msg":"registering targets","arn":"arn:aws:elasticloadbalancing:us-east-1:7550XXXXXXXX:targetgroup/helloworld-8080-a8054/5741da332459b560","targets":[{"AvailabilityZone":"all","Id":"10.244.0.22","Port":8080}]}
{"level":"info","ts":"2024-05-13T03:24:34Z","msg":"registered targets","arn":"arn:aws:elasticloadbalancing:us-east-1:7550XXXXXXXX:targetgroup/helloworld-8080-a8054/5741da332459b560"}

Documentation and tests were properly updated in this PR

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the docs directory)
• Manually tested
• Made sure the title of the PR is a good description that can go into the release notes

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

A working amd64 container with this code is available here: marcosdiez/aws-load-balancer-controller:v2.7.2-m2

[k8s-ci-robot]

Hi @marcosdiez. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions 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-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: marcosdiez
Once this PR has been reviewed and has the lgtm label, please assign johngmyers for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marcosdiez]

@shraddhabang I believe my code is ready. Feel free to review at will! Thank you.

Also, if you don't want the CRDs to be changed, here:
126c9c8

they are untouched.

[shraddhabang]

Thank you @marcosdiez for this PR. This looks excellent.
I will take a look and test it out. And would also ask our team to review it. Please note that we will have to go through our formal security process to review this. We will add this to our next minor release v2.9.0.
Please feel free to reach out to us.

[shraddhabang]

/ok-to-test