Change:
// Note that this is annoying: the load balancer disappears from the API immediately, but it is still // deleting in the background.  We get a DependencyViolation until the load balancer has deleted itself <ins> var loadBalancerSGs = aws.StringValueSlice(lb.SecurityGroups) describeRequest := &ec2.DescribeSecurityGroupsInput{} filters := []*ec2.Filter{ newEc2Filter("group-id", loadBalancerSGs...), } describeRequest.Filters = c.tagging.addFilters(filters) response, err := c.ec2.DescribeSecurityGroups(describeRequest) if err != nil { return fmt.Errorf("error querying security groups for ELB: %q", err) } </ins> // Collect the security groups to delete securityGroupIDs := map[string]struct{}{} <del> for _, securityGroupID := range lb.SecurityGroups { if *securityGroupID == c.cfg.Global.ElbSecurityGroup { //We don't want to delete a security group that was defined in the Cloud Configurationn. </del> <ins> for _, sg := range response { sgID := aws.StringValue(sg.GroupId) if sgID == c.cfg.Global.ElbSecurityGroup { //We don't want to delete a security group that was defined in the Cloud Configuration. </ins> continue } <del> if aws.StringValue(securityGroupID) == "" { klog.Warning("Ignoring empty security group in ", service.Name) </del> <ins> if sgID == "" { klog.Warningf("Ignoring empty security group in %s", service.Name) </ins> continue } <del> securityGroupIDs[*securityGroupID] = struct{}{} </del> <ins> if !c.tagging.hasClusterTag(sg.Tags) { klog.Warningf("Ignoring security group with no cluster tag in %s", service.Name) continue } securityGroupIDs[sgID] = struct{}{} </ins> } // Loop through and try to delete them

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When specifying multiple services using the annotation the SG defined in that annotation may be the one used for ingress to the instances. If this happens for multiple service ELBs and one of those services is removed then the rule may be removed during clean up causing the other ELBs losing the ability to contact their instances. What you expected to happen: Removal of any service should not lead to disruption of other services. How to reproduce it (as minimally and precisely as possible): a security group in AWS. multiple services referencing that SG in . one of those services. Environment: Kubernetes version (use ): 1.8.8 Cloud provider or hardware configuration: AWS Kernel (e.g. ): 4.4.121-k8s
From what I can tell this is a result of the simple selection of what to consider the LB security group here: I'd think a solution would be to prefer an SG tagged as kube owned if one is present (which there should always be if one is created for the LB as expected). I should be able to get a PR together if that sounds like an appropriate fix.
This may also be related to
/sig aws
Also
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I have a Kubernetes () in AWS. I created a Service of type and used the annotation to apply an extra security group to the ELB that gets created. The extra security group was created outside of Kubernetes, with the expectation that it is not owned by Kubernetes and will be managed independently. I deleted the Service resource. Kubernetes then deleted the ELB and my extra security group. What you expected to happen: I expect my extra security group to not be deleted. How to reproduce it (as minimally and precisely as possible): In AWS, create security group that is otherwise unused. In Kubernetes, create Service of type , include the annotation with the previously created security group. Watch an ELB be created with that security group. Delete the Service from Kubernetes. Watch the ELB be deleted (as expected) and the security group be deleted (unexpected). Anything else we need to know?: It seems a workaround may be to ensure the security group is in use by at least one other resource within AWS so that the deletion attempt will fail with a . The deletion process will eventually timeout, if I understand the code correctly. I've linked to , though I don't see any additional behavior on , so I believe the bug is there as well. Environment: Kubernetes version (use ): v1.7.16 Cloud provider or hardware configuration: AWS
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I have also experienced this same issue luckily we have a very strict iam policy for k8s in aws and did not give the controller access to delete the 'extra-security-group` we specified in the annotation. There also seems to not be a try/catch around deleting security groups when deleting ELBs.

The flow looks like the following: 1) Fetch security groups associated with ELB 2) For each security group try to delete the security group, if the security group fails to delete do not move on to the next security group to delete In this scenario the security group that is created by k8s for this ELB does not get deleted and is left behind. Here are some relevant logs, is the k8s generated sg is the security group specified in the annotation We are using version
I believe the solution should be to only have k8s try to delete security groups that it has ownership tags for.
Another solution could be while to "delete" subtract the set from the annotation aws-load-balancer-extra-security-groups
A "workaround" for this issue is to add the SG as a source in the nodes SG
I'm hitting the same issue on this one and it's causing cluster networking issues - Kubernetes deletes a shared SG which breaks my API access - I have the shared ownership tag to the security group but it is still removed. Any ideas?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
This issue is affecting me as well.