Security Groups and Security Group Rules

Security Groups

A security group is a collection of access control rules for cloud resources, such as cloud servers, containers, and databases, that have the same security protection requirements and that are mutually trusted. After a security group is created, you can configure access rules that will apply to all cloud resources added to this security group.

When creating an instance (for example, an ECS), you must associate it with a security group. If there are no security groups yet, a default security group will be automatically created and associated with the instance. You can also create a security group based on service requirements and associate it with the instance. A cloud resource can be associated with multiple security groups, and traffic to and from the cloud resource is matched by priority in a descending order.

Each security group can have both inbound and outbound rules. You need to specify the source, port, and protocol for each inbound rule and specify the destination, port, and protocol for each outbound rule to control the inbound and outbound traffic to and from the instances in the security group. As shown in Figure 1, you have a VPC (VPC-A) with a subnet (Subnet-A) in region A. An ECS (ECS-A) is running in Subnet-A and associated with security group Sg-A.

• Security group Sg-A has a custom inbound rule to allow ICMP traffic to ECS-A from your PC over all ports. However, the security group does not contain rules that allow SSH traffic to ECS-A so you cannot remotely log in to ECS-A from your PC.
• If ECS-A needs to access the Internet through an EIP, the outbound rule of Sg-A must allow all traffic from ECS-A to the Internet.

Figure 1 Security group architecture

You can use security groups free of charge.

Security Group Rules

• A security group has inbound and outbound rules to control traffic that's allowed to reach or leave the instances associated with the security group.
  • Inbound rules: control traffic to the instances in a security group.
  • Outbound rules: control traffic from the instances in a security group for accessing external networks.
• You can specify protocol, port, source or destination for a security group rule. The following describes key information about a security group.
  • Action: Allow or Deny. If the protocol, port, source or destination of the traffic matches a security group rule, traffic will be allowed or denied.
  • Priority: The value ranges from 1 to 100. A smaller value indicates a higher priority. Security group rules are matched by priority and then by action. Deny rules take precedence over allow rules. For more information, see How Traffic Matches Security Group Rules.
  • Type: IPv4 or IPv6.
  • Protocol & Port: network protocol type and port range.
    • Network protocol: The protocol can be TCP, UDP, ICMP, or GRE.
    • Port range: The value ranges from 1 to 65535.
  • Source or Destination: source address of traffic in the inbound direction or destination address of traffic in the outbound direction.
    The source or destination can be an IP address, security group, or IP address group.

    • IP address: a fixed IP address or CIDR block. Both IPv4 and IPv6 addresses are supported, for example, 192.168.10.10/32 (IPv4 address), 192.168.1.0/24 (IPv4 CIDR), or 2407:c080:802:469::/64 (IPv6 CIDR).
    • Security group: If the selected security group and the current security group are in the same region, the traffic is allowed or denied to the private IP addresses of all instances in the selected security group. For example, if there is instance A in security group A and instance B in security group B, and the inbound rule of security group A allows traffic from security group B, traffic is allowed from instance B to instance A.
    • IP address group: If you have multiple IP addresses with the same security requirements, you can add them to an IP address group and select this IP address group when you configure a rule, to help you manage them in a more simple way.

How Security Groups Work

• Security groups are stateful. If you send a request from your instance and the outbound traffic is allowed, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Similarly, if inbound traffic is allowed, responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.
• Security groups use connection tracking to track traffic to and from instances. If an inbound rule is modified, the modified rule immediately takes effect for the existing traffic. Changes to outbound security group rules do not affect existing persistent connections and take effect only for new connections.

  If you add, modify, or delete a security group rule, or add or remove an instance to or from a security group, the inbound connections of all instances in the security group will be automatically cleared.

  • The existing inbound persistent connections will be disconnected. All the new connections will match the new rules.
  • The existing outbound persistent connections will not be disconnected, and the original rule will still be applied. All the new connections will match the new rules.

After a persistent connection is disconnected, new connections will not be established immediately until the timeout period of connection tracking expires. For example, after an ICMP persistent connection is disconnected, a new connection will be established and a new rule will apply when the timeout period (30s) expires.

• The timeout period of connection tracking varies by protocol. The timeout period of a TCP connection in the established state is 600s, and that of an ICMP connection is 30s. For other protocols, if packets are received in both inbound and outbound directions, the connection tracking timeout period is 180s. If packets are received only in one direction, the connection tracking timeout period is 30s.
• The timeout period of TCP connections varies by connection status. The timeout period of a TCP connection in the established state is 600s, and that of a TCP connection in the FIN-WAIT state is 30s.

• Security group rules are like a whitelist. If there are no rules that allow or deny some traffic, the security group denies all traffic to or from the instances in the security group.
  • Inbound rules: If the source of a request matches the source specified in a rule with Action set to Allow, the request is allowed. For this reason, you do not need to configure a deny rule in the inbound direction.

    The rules in Table 1 ensure that instances in a security group can communicate with each other. Do not delete or modify these rules.

  • Outbound rules: The rules in Table 1 allow all traffic to leave the instances in the security group so that the instances can access any external IP address. If you delete these rules, the instances in the security group cannot access external networks.

    Table 1 Security group rules

    Direction	Action	Type	Protocol & Port	Source/Destination
    Inbound	Allow	IPv4	All	Source: current security group
    Inbound	Allow	IPv6	All	Source: current security group
    Outbound	Allow	IPv4	All	Destination: 0.0.0.0/0
    Outbound	Allow	IPv6	All	Destination: ::/0

How Traffic Matches Security Group Rules

An instance can have multiple security groups associated, and a security group can contain multiple security group rules. Security group rules are matched by priority and then by action. Deny rules take precedence over allow rules. The following takes inbound traffic as an example to match security group rules:

1. First, traffic is matched based on the sequence number of security groups. You can adjust the security group sequence. A smaller security group sequence number indicates a higher priority.

   If the sequence number of security group A is 1 and that of security group B is 2, the priority of security group A is higher than that of security group B. Traffic preferentially matches the inbound rules of security group A.

2. Second, traffic is matched based on the priorities and actions of security group rules.
   1. Security group rules are matched by priority first. A smaller value indicates a higher priority.

      If the priority of security group rule A is 1 and that of security group rule B is 2, the priority of security group rule A is higher than that of security group rule B. Therefore, traffic preferentially matches security group rule A.

   2. Deny rules take precedence over allow rules of the same priority.
3. Traffic matches all inbound rules of a security group based on the protocol, ports and source.
   • If the traffic matches a rule:
     • With Action of Allow, the traffic is allowed to access the instances in the security group.
     • With Action of Deny, the traffic is denied to access the instances in the security group.
   • If the traffic does not match any rule, the traffic is denied to access the instances in the security group.

Figure 2 Security group matching sequence

How Security Groups Are Used

You can allow given IP addresses to access instances in a security group, or allow access from another security group to enable instances in different security groups to communicate with each other. You can add security group rules to flexibly control the traffic in and out of a network to ensure network security. The following provides some security group configuration examples.

Security Group Configuration Process

Figure 6 Process of using a security group

Security Group Constraints

• For better network performance, you are advised to associate an instance with no more than five security groups.
• A security group can have no more than 6,000 instances associated, or its performance will deteriorate.
• For inbound security group rules, the sum of the rules with Source set to Security group, the rules with Source set to IP address group, and the rules with inconsecutive ports, cannot exceed 128. Outbound rules also have this restriction.
  • When Source is set to Security group, you can select the current security group or a different security group.
  • An example of inconsecutive ports is 22,25,27.
• If you specify an IP address group or inconsecutive ports for a security group rule, the rule is only applied for certain ECSs. For details, see Table 3.

  Table 3 Scenarios that security group rules do not take effect

  Rule Configuration	ECS Type
  Source or Destination is set to IP address group.	The following x86 ECS types are not supported: General computing (S1, C1, and C2 ECSs) Memory-optimized (M1 ECSs) High-performance computing (H1 ECSs) Disk-intensive (D1 ECSs) GPU-accelerated (G1 and G2 ECSs) Large-memory (E1, E2, and ET2 ECSs)
  Port is set to non-consecutive ports.	The following x86 ECS types are not supported: General computing (S1, C1, and C2 ECSs) Memory-optimized (M1 ECSs) High-performance computing (H1 ECSs) Disk-intensive (D1 ECSs) GPU-accelerated (G1 and G2 ECSs) Large-memory (E1, E2, and ET2 ECSs)
  	All Kunpeng ECS flavors do not support inconsecutive ports. If you use inconsecutive port numbers in a security group rule of a Kunpeng ECS, this rule and rules configured after this one do not take effect. If you configure security group rule A with inconsecutive ports 22,24 and then configure security group rule B with port 9096, both rule A and rule B do not take effect.

  

  • For details about x86 ECSs, see ECS Specifications (x86).
  • For details about Kunpeng ECSs, see ECS Specifications (Kunpeng).

Recommendations

• Instances in a security group deny all external access requests by default, but you can add rules to allow specific requests.
• When adding a security group rule, grant the minimum permissions possible. For example, if remote login to an ECS over port 22 is allowed, only allow specific IP addresses to log in to the ECS. Do not use 0.0.0.0/0 (all IP addresses).
• Keep your configurations simple. There should be a different reason for each security group. If you use the same security group for all your different instances, the rules in the security group will likely be redundant and complex. It will make it much harder to maintain and manage.
• You can add instances to different security groups based on their functions. For example, if you want to provide website services accessible from the Internet, you can add the web servers to a security group configured for that specific purpose and only allow external access over specific ports, such as 80 and 443. By default, other external access requests are denied. Do not run internal services, such as MySQL or Redis, on web servers that provide services accessible from the Internet. Deploy internal services on servers that do not need to connect to the Internet and associate these servers with security groups specifically configured for that purpose.
• If you have multiple IP addresses with the same security requirements, you can add them to an IP address group and select this IP address group when you configure a rule, to help you manage them in a more simple way. When an IP address changes, you only need to change the IP address in the IP address group. Then, the rules in the IP address group change accordingly. You do not need to modify the rules in the security group one by one. This simplifies security group management and improves efficiency. For details, see Using IP Address Groups to Reduce the Number of Security Group Rules.
• Do not directly modify security group rules for active services. Before you modify security group rules used by a service, you can clone the security group and modify the security group rules in the test environment to ensure that the modified rules work. For details, see Cloning a Security Group.
• After you add instances to or modify rules of a security group, the security group rules are applied automatically. There is no need to restart the instances.

  If a security group rule does not take effect after being configured, see Why Are My Security Group Rules Not Applied?