Don't create an additional SecurityGroups if it's already defined by aws-load-balancer-security-groups annotation about cloud-provider-aws

[DzmitrySudnik]

More over, it never cleans that security groups leaving it orphaned clattering your account and eventually hitting a limit.

[ivan-sukhomlyn]

@yevhen-kalyna Thanks for your suggestion.
I already did it.
But this bug is still present.
The provider creates redundant resources and rewrites a defined one in the cloud instead of using the provided security group in case when I want to configure access to LB exactly via SecurityGroup (by another SG definition in inbound/outbound rules) instead of IP ranges.

[lbontecou]

Ran into this while trying to create an ELB with a whitelist only open to a 3rd party. Our intention was to make the whitelisted security-group a terraform managed resource used by multiple load balancers.

$ k version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:18:23Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.12-eks-c500e1", GitCommit:"c500e11584c323151d6ab17526d1ed7461e45b0c", GitTreeState:"clean", BuildDate:"2019-10-22T03:11:52Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}

[yevhen-kalyna]

Just use additional annotation load-balancer-source-ranges to your current annotations :

annotations:
    service.beta.kubernetes.io/load-balancer-source-ranges: ["x.x.x.x/xx","x.x.x.x/xx"]

And you will get rules dedicated to your IPs.
@ivan-sukhomlyn

[ivan-sukhomlyn]

The fix has been prepared and merged into Kubernetes master branch kubernetes/kubernetes#83446
It will be released with the 1.18 Kubernetes version