Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ivan-sukhomlyn opened this issue Nov 27, 2019 · 5 comments
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@ivan-sukhomlyn
Copy link

What happened:
AWS Cloud provider creates an additional AWS Security Group per LoadBalancer defined in Kubernetes Service configuration in case if it's already defined by service.beta.kubernetes.io/aws-load-balancer-security-groups annotation

What you expected to happen:
Don't create an additional SG and don't rewrite rules on SG provided by aws-load-balancer-security-groups annotation

How to reproduce it (as minimally and precisely as possible):

  1. Create SG with rules for ELB
  2. Create a K8S service with existing SG defined by annotation service.beta.kubernetes.io/aws-load-balancer-security-groups and Type: LoadBalancer
    For example,
$ kubectl describe service some-service
Name:  some-service

Annotations: service.beta.kubernetes.io/aws-load-balancer-security-groups: sg-some-id
....
Type:  LoadBalancer
  1. Then AWS Cloud provider creates an additional SG and replaces custom rules to the existing Security Group
    Anything else we need to know?:
    Creates SG by cloud provider:
    Screenshot 2019-11-27 at 3 42 07 PM
    My custom SG after several seconds after service creation:
    Screenshot 2019-11-27 at 3 42 22 PM

Environment:

  • Kubernetes version (use kubectl version):
    v1.14.8-eks-b7174d
  • Cloud provider or hardware configuration:
    AWS

/kind bug

@k8s-ci-robot k8s-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Nov 27, 2019
@DzmitrySudnik
Copy link

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

@lbontecou
Copy link

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
Copy link

yevhen-kalyna commented Jan 30, 2020

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
Copy link
Author

@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.

@ivan-sukhomlyn
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

5 participants