[EKS] [request]: Allow cloud provider config. setting DisableSecurityGroupIngress

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
Could EKS allow us to specify cloud provider parameters such as DisableSecurityGroupIngress and ElbSecurityGroup?

**Which service(s) is this request for?**
EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**

My company is trying to migrate from self-managed Kubernetes to EKS. Our current setup consists of several hundred type LoadBalancer Service resources. Each developer manages their own ingress to the cluster in this way. When trying to migrate this workload, we ran into an error from reaching the maximum inbound or outbound rules per security group. I am aware of:

https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html#vpc-limits-security-groups

and the recent updates: https://aws.amazon.com/premiumsupport/knowledge-center/increase-security-group-rule-limit/

But even these possible increases are not enough to "lift-and-shift" our workload. It's not possible for us to undertake a significant refactor in order to migrate to EKS at this time.

**Are you currently working around this issue?**
How are you currently solving this problem?

We currently manage security group creation manually. We set the cloud provider config. file with the options:

```
[Global]
DisableSecurityGroupIngress = true
ElbSecurityGroup = sg-XXX <== This is a group with 0 ingress/egress rules
```

And pass `--cloud-config=` to our control plane components and kubelets. Then we manage both the Node security group/ELB security group outside of Kubernetes. A SG is created for the ELB and attached to the node SG's ingress rules. Then we add the following annotation to the Service manifest to attach it:

```
service.beta.kubernetes.io/aws-load-balancer-extra-security-groups
```

This solution gives us the control we need to stay within the security group limitations.

Refer to:
https://github.com/kubernetes/cloud-provider-aws/commit/dbc66dc675eee8b53c399a5c300122e37d3fade0
https://forums.aws.amazon.com/thread.jspa?messageID=896987

**Additional context**

I am aware of other possible workarounds, such as:

* Sharing a single AWS load balancer amongst multiple applications and deploying an ingress controller. We have concerns over this from a blast radius perspective - one poorly behaving application can trigger outages for others, refer to https://aws.amazon.com/premiumsupport/knowledge-center/elb-capacity-troubleshooting/

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start by reviewing the referenced cloud-provider-aws commit and the EKS cloud provider configuration described in the issue, then confirm how DisableSecurityGroupIngress and ElbSecurityGroup are handled for EKS. Done means EKS supports these parameters or documents an approved equivalent for managing load-balancer security groups without automatic ingress rules.

Written by the indexing model from the issue text.