Support optimized security group rules for ALB

[kishorj]

Issue

Issue: #2118

Description

Add support for using shared backend security groups for ALB. This will result in using a constant number of SG rules per cluster for the purpose of allowing access to ALB traffic. Also enable management of security group rules for manually specified security groups. For details refer to issue #2118.

Tests

• Backend SG feature get enabled by default, SG is auto-generated if needed, sg name is of the format k8s--traffic-<15 hex chars of sha256(clusterName + VPCID)>
• backend SG is attached to the ALB
• Ingress rule gets added to the instance security group to allow ALB traffic
• Ingresses in the same cluster share the backend SG
• backend SG gets deleted automatically if no longer needed
• Ingresses with alb.ingress.kubernetes.io/security-groups annotation don't use the backend SG by default
• When alb.ingress.kubernetes.io/manage-security-group-rules: "true" annotation is applied to ingress with manual SG configuration, the backend SG gets attached to the corresponding ALB, and the node SG gets updated to allow traffic
• With manual security group configuration and manage rules set to true on an ingress, model builder returns error if backend security group feature is not enabled
• When backend SG feature is disabled via the controller flag, the auto-generated SG gets used in the node SG rules as before
• Backend SGs can be configured via command line flag --backend-security-groups in lieu of auto-generated ones

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 🌟

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[codecov-commenter]

Codecov Report

Merging #2205 (cf095ae) into main (7b3d25d) will increase coverage by 0.79%.
The diff coverage is 68.62%.

@@            Coverage Diff             @@
##             main    #2205      +/-   ##
==========================================
+ Coverage   52.39%   53.18%   +0.79%     
==========================================
  Files         133      135       +2     
  Lines        7257     7446     +189     
==========================================
+ Hits         3802     3960     +158     
- Misses       3158     3178      +20     
- Partials      297      308      +11     

Impacted Files	Coverage Δ
pkg/config/controller_config.go	20.00% <0.00%> (-5.65%)	⬇️
pkg/ingress/model_build_managed_sg.go	66.66% <ø> (-0.65%)	⬇️
pkg/networking/backend_sg_provider_mocks.go	0.00% <0.00%> (ø)
pkg/ingress/model_builder.go	63.63% <57.14%> (+0.71%)	⬆️
pkg/ingress/model_build_load_balancer.go	61.86% <58.97%> (+9.90%)	⬆️
pkg/networking/backend_sg_provider.go	90.35% <90.35%> (ø)
pkg/ingress/model_build_target_group.go	73.74% <100.00%> (+0.77%)	⬆️
... and 1 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7b3d25d...cf095ae. Read the comment docs.

[kishorj]

/retest

[M00nF1sh]

personally i feel this depends on ingress implementation details too much.

also, seems the backendSG is not cleaned if there are some ingress in cluster even the left Ingresses don't need the backendSG.

shall we have a dedicated finalizer so that only ingresses/services needs backSG is added these finalizers?
if we have that, we can

call a dedicated function to test whether ingress/service needs backendSG, and then add this dedicated finalizer and invoke backendSGProvider.Get inside the group controller, and pass obtained backendSG into modelBuilder.
and then call backendSGProvider.Release if any group member have this finalizer, and remove the finalizer if it succeeds.

Or instead of add the finalizer in groupController, we have library some adds the finalizer before we create any cluster/controller-specific resources like backendSG, (e.g. make backendSGProvider.Get accepts a list of k8s resources as well).

i guess we could have a lot cluster/controller-specific resources like this backendSG in the future, e.g. a lambda function used to rewrite http requests for albs to do path rewrite)

[M00nF1sh]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kishorj, M00nF1sh

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [M00nF1sh,kishorj]

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