Add referencing existing security groups for inbound traffic

[changhyuni]

Is your feature request related to a problem?
Enable more flexible management of security groups, I add a security group source chaining feature to inbound security groups. This is great for allowing traffic from public IP spaces, but for internal ALBs, it would be ideal to allow inbound traffic from specific security groups. For instance, allowing API Gateway traffic (via VPC Link) to an ALB without exposing the ALB to the entire subnet or VPC. It would be preferable to reference the security group of the VPC Link. Similarly, you might want to allow a specific EC2 instance (not part of the EKS cluster) to connect to an ALB while restricting access for another EC2 instance.

Describe the solution you'd like
The ALB should support security group chaining in inbound security groups. This is a key feature.

Describe alternatives you've considered
Instead of referencing security groups, you can use CIDR blocks to define inbound rules. However, this approach lacks the granularity and specificity of using security groups, as it might require opening broader IP ranges and can increase the attack surface.

Related items
#3829 (PR)
#2688

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale