If a security group is deleted the rules in the security group will be deleted as well

Community Note

• Please vote on this issue by adding a 👍 reaction 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
When a Kubernetes service is deleted, EKS deletes the ELB associated with that service. In our case, the ELB has a shared security group applied on it, which is an inbound security group rule for other security groups. When the ELB is deleted, EKS deletes the shared security group as well, removing the inbound rule on other security groups and disrupts communication in our cluster.

EKS should not delete security groups it did not create, it should disassociate them. EKS should only delete security groups that it itself has created.

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?
EKS should not delete security groups from ELBs it did not create. This action is taken automatically from EKS when deleting a Kubernetes service, and we have no control to change it.

Are you currently working around this issue?
We can no longer delete a Kubernetes service directly. We are using a separate flow which involves disassociating the shared security group before deleting the ELB.

Amazon Web Services: Virtual Private Cloud security groups

A security group is like a virtual firewall. It works much like a traditional firewall does.

It consists of a set of rules that can be used to monitor and filter an instance's incoming and outgoing traffic in a Virtual Private Cloud (VPC) instance. Filtering is done on the basis of protocols and ports.

An instance can be assigned with a maximum of five security groups. Unlike network access control lists (ACLs), which operate at the subnet level, security groups operate at the instance level. Therefore, it's not necessary to assign the same set of security groups to every instance in a subnet. Every instance is allowed to have a different set of security groups.

On top of this, security groups can be assigned to multiple instances.

• Security groups are permissive. You cannot have a rule to deny access.
• They are stateful. Irrespective of the inbound rules, if you send a request from your instance, the response traffic for that request will be automatically allowed. For VPC security groups, the responses to allowed inbound traffic can leave the instance irrespective of outbound rules.
• By default, they allow all outbound traffic.By default, they allow all outbound traffic.
• Every VPC includes a default security group.

Every VPC includes a default security group. If you do not specify a security group while launching an instance, the default security group will be assigned to it.

However, at anytime, you can define a new security group using the Amazon EC2 console.

The default security group comes with the following built-in rules:

• The inbound traffic coming from instances associated with the default security group will be allowed.
• All outbound traffic originating from the instance is allowed.

Nevertheless, you can modify the default security group’s rules.

The default security group cannot be deleted. If you attempt to delete it, the following error will be displayed:

Client.CannotDelete: the specified group: "sg-51320848" name: "default" cannot be deleted by a user.

Every security group consists of a set of rules. The security group examines all of its rules before allowing any traffic to enter or leave the instance. The rules that are used to control the inbound traffic are independent of the rules that are used to control the outbound traffic.

When a new security group is created, initially all inbound traffic is restricted and outbound traffic is allowed. Therefore, you need to add rules to the group to permit incoming traffic and to apply restrictions on the outbound traffic.

There is a limit, known as VPC quotas, on the number of rules that can be created for a security group. A security group can have a maximum of 120 rules. Out of the 120 rules, 60 rules are inbound rules and 60 rules are outbound rules. The limit of 120 rules is imposed separately for IPv4 and IPv6 rules. This means a security group can have 60 inbound rules and 60 outbound rules for IPv4 traffic and 60 inbound rules and 60 outbound rules for IPv6 traffic.

Since an instance can have multiple security groups associated with it, all the rules from each security group associated with the instance are combined together to form a single set of rules. This set of rules is used to determine whether the traffic should be denied or allowed into the instance.

For every security rule that you add to the security group, you need to specify the values for the following six fields:

• Type: Indicates the protocol type. Select the required protocol, say HTTP or SSH, from the drop-down list. Custom protocols are also included in the list.
• Protocol: This is usually covered by Type. So this field will be greyed out. However, if you had created a custom rule, you can state a protocol, like TCP or UDP for example
• Port Range: This value will be filled automatically depending upon the default port or port range of the protocol you chose. You can also use custom ports if you'd like.
• ICMP Type and Code.
• Source (inbound rules) or Destination (outbound rules): You can specify a particular IP Address, an AWS security group, or a subnet.

Note: If you specify 0.0.0.0/0 as the IP Address, anyone will be able to access the instance.

• Description: You can include a description for the rule. The convention for this is the same as the one for security group description.

It's also important to note that only rules to allow traffic can be defined in the security group. Rules to deny traffic cannot be defined.

The following steps will guide you through the entire process of creating and managing a security group as well as the security group rules.

How to create a security group using the AWS Management Console 

Every new instance comes with a default security group. However, Amazon VPC also provides you with the option to create your own security groups.

You can also create a security group by employing the command line.

Conventions for naming and providing a description for a security group  

How to change the security groups associated with an instance 

How to delete a security group from a VPC 

How to view the list of all security groups 

How to create a copy of a security group 

Any addition or modification of the rules of a security group will be applied to all instances linked to that particular security group.

By default, a new security group by default consists of a single outbound rule that permits all outbound traffic. In order to permit only certain outbound traffic to leave your instance, you can remove this rule and add specific outbound rules that restrict the traffic. The below steps will guide you to add and modify rules in a security group.

Adding a rule to the security group using VPC Console 

Deleting a rule in the security group using the VPC Console 

Modifying a rule in the security group using the VPC Console  

When a security group rule is referencing another security group in a peer VPC, if the referenced security group is deleted or if the peer connection has been deleted, the security group rule becomes obsolete. Such rules are known as stale security group rules. They will not be deleted automatically and have to be deleted manually.

Deleting or modifying a stale rule in a security group using the VPC Console:

If another peer connection is established between the same VPCs after deletion of the original peer connection, the security group rules will no longer be stale.