What Is a Security Group?
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.
Many cloud services can use security groups, such as ECS, RDS, DDS, DDM, MRS, CCE, CSS, DCS (Redis 3.0), DMS, WAF, and SFS.
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. For details, see Default Security Groups. 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 have 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 A security group architecture
What Are Security Group Rules?
- A security group has inbound and outbound rules to control traffic that is 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 to access external networks.
- You can specify protocol, port, source or destination for a security group rule. The following describes key information about a security group rule.
- 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 first 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.
- Protocol: the protocol that is used to match traffic. The protocol can be TCP, UDP, ICMP, or GRE.
- TCP is ideal for applications that require reliable connections and high data integrity, such as remote login, web browsing, email, and file transfers.
- UDP is ideal for applications demanding high speed and low latency, such as online gaming and video meetings.
- ICMP is used to communicate data transmission problems. For example, the ping command can be used to check the connectivity between network devices, error reports can be generated for O&M, and diagnosis information can be transmitted for network analysis and optimization.
- GRE is widely used and enables communications between networks using different protocols by encapsulating one protocol within another, for example, encapsulating IP packets.
- Port: the destination port range that is used to match traffic. The value ranges from 1 to 65535.
- Protocol: the protocol that is used to match traffic. The protocol can be TCP, UDP, ICMP, or GRE.
- 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 an easier 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 how inbound security group rules are defined. Similarly, if inbound traffic is allowed, responses to allowed inbound traffic are allowed to flow out, regardless of how outbound rules are defined.
- Security groups use connection tracking to track traffic to and from instances. Changes to inbound rules take effect immediately for existing connections. Changes to outbound security group rules do not affect existing persistent connections and take effect only for new connections.
If you add, delete, or update rules in a security group, or add or remove instances in a security group, the details are as follows:
- For connections established by inbound traffic, the system automatically clears the connection tracking entries corresponding to the existing persistent connections based on Table 1. That is, the connection tracking entries are expired in advance. Then, the system re-establishes connections to match the new inbound rules of the security group.
- If the security group rules allow the traffic of the connections, the connections can be established and network communication is not affected.
- If the security group rules deny the traffic of the connections, the connections cannot be established again and the network communication will be interrupted.
Table 1 Scenarios and policies for clearing connection tracking entries Scenario
Clearing Policy
Adding instances to security group A
- Clear inbound connection tracking entries of the instances newly added to security group A.
- If an inbound rule of another security group (for example, security group B) denies access from security group A, clear inbound connection tracking entries of all instances in security group B.
Removing instances from security group A
- Clear inbound connection tracking entries of all instances in security group A.
- If an inbound rule of another security group (for example, security group B) allows access from security group A, clear inbound connection tracking entries of all instances in security group B.
Adding rules to security group A
If a Deny rule is added in the inbound or outbound direction, clear inbound connection tracking entries of all instances in security group A.
Deleting rules from security group A
If an Allow rule is deleted in the inbound direction, clear inbound connection tracking entries of all instances in security group A.
Modifying rules in security group A
If the priority, action, protocol, port, or source address of a rule is modified in the inbound direction, clear inbound connection tracking entries of all instances in security group A.
Changing IP address entries in an IP address group
If an IP address group is associated with an inbound rule in security group A, deleting or adding an IP address entry from or to the IP address group will clear inbound connection tracking entries of all instances in security group A.
- 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.
- For connections established by inbound traffic, the system automatically clears the connection tracking entries corresponding to the existing persistent connections based on Table 1. That is, the connection tracking entries are expired in advance. Then, the system re-establishes connections to match the new inbound rules of the security group.
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 be applied 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 work like a whitelist. If there are no rules that allow or deny some traffic, the security group denies such 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 2 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 2 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 2 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
- 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.
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 first 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:
- 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.
- Second, traffic is matched based on the priorities and actions of security group rules.
- 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.
- Deny rules take precedence over allow rules of the same priority.
- Security group rules are matched by priority first. A smaller value indicates a higher priority.
- 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.
- If the traffic matches a rule:
Figure 2 Security group matching sequence
Security Group Examples
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 examples on how security groups can be used.
Allowing Traffic from Given IP Addresses or Security Groups
In Figure 3, there are two subnets (Subnet-A and Subnet-B) in VPC-X. ECSs in Subnet-A are associated with Sg-A because these ECSs are used to run the same services and have the same network communication requirements. Similarly, ECSs in Subnet-B are associated with security group Sg-B.
- Inbound rule A01 of Sg-A allows traffic from IP addresses in 172.16.0.0/24 to access SSH port 22 of the ECSs in Sg-A for remotely logging in to these ECSs.
- Inbound rule A02 of Sg-A allows the ECSs in this security group to communicate with each other using any protocol and port.
- Inbound rule B01 of Sg-B allows the ECSs in Sg-A to access the ECSs in Sg-B SSH port 22. That is, ECSs in Subnet-A can remotely log in to the ECSs in Subnet-B.
- Inbound rule B02 of Sg-B allows the ECSs in this security group to communicate with each other using any protocol and port. That is, ECSs in Subnet-B can communicate with each other.
- The outbound rules of both security groups allow all traffic from the ECSs in the security groups.
Figure 3 Allowing traffic from given IP addresses and security groups
Security Group Examples lists more security group rule configuration examples.
Allowing Traffic from a Virtual IP Address
If you use an intermediate network instance to forward traffic between instances in different subnets, setting the source of the inbound rule to the security group associated with the peer instance does not allow the instances to communicate with each other. To enable communications, set the source to the private IP address or subnet CIDR block of the intermediate network instance. For example, to connect ECSs in Subnet-A and Subnet-B in Figure 4, set the source of the inbound rule to the virtual IP address.
In Figure 4, VPC-X has two subnets: Subnet-A and Subnet-B. ECSs in Subnet-A are associated with security group Sg-A, and ECSs in Subnet-B are associated with security group Sg-B. ECS-A01 and ECS-A02 work in active/standby pair, forming a Keepalived HA cluster. The ECSs use virtual IP address 192.168.0.21 to communicate with external networks.
- Inbound rule A01 of Sg-A allows ECSs in Sg-B to access ECSs in Sg-A using any protocol over any port.
- Sg-B has the following inbound rules:
- Rule B02: Allows ECSs in Sg-A to use private IP addresses to access ECSs in Sg-B. However, in this network, ECSs in Sg-A are supposed to communicate with ECSs in Sg-B through virtual IP address 192.168.0.21. However, rule B02 does not allow traffic from this virtual IP address.
- Rule B01: Allows traffic from virtual IP address 192.168.0.21 to ECSs in Sg-B using any protocol over port. In this networking, you can also set the source to 192.168.0.0/24, the CIDR block of Subnet-A.
Figure 4 Allowing traffic from a virtual IP address
Security Group Examples lists more security group rule configuration examples.
Allowing Communications Between Instances in Two VPCs Connected by a VPC Peering Connection
In Figure 5, VPC-A and VPC-B in region A are connected by VPC peering connection peering-AB. After routes are configured for the VPC peering connection, Subnet-A01 and Subnet-B01 can communicate with each other. However, the ECSs in the two subnets are associated with different security groups. To allow ECSs in Sg-A and Sg-B to communicate with each other, you can add the following rules:
- Rule A01 with Source to Sg-B to allow ECSs in Sg-B to access ECSs in Sg-A.
- Rule B01 with Source to Sg-A to allow ECSs in Sg-A to access ECSs in Sg-B.
Figure 5 Allowing communications between ECSs in two VPCs connected by a VPC peering connection
Security Group Examples lists more security group rule configuration examples.
Security Group Configuration Process
Figure 6 Process of using a security group
No. | Step | Description | Reference |
|---|---|---|---|
1 | Create a security group. | When creating a security group, you can use the preset rules. For details about the preset security group rules, see Table 1. | |
2 | Configure security group rules. | After a security group is created, if its rules cannot meet your service requirements, you can add new rules to the security group or modify original rules. | |
3 | Add instances to the security group. | When you create an instance, the system automatically adds the instance to a security group for protection. If one security group cannot meet your requirements, you can add an instance to multiple security groups. |
Constraints on Using Security Groups
- By default, you can add up to 50 security group rules to a security group.
- By default, you can associate no more than five security groups with each cloud server or extended network interface. In such a case, the rules of all the selected security groups are combined and applied together.
- 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, of the rules with Source set to IP address group, and of the rules with inconsecutive ports, cannot exceed 120. If there are both IPv4 and IPv6 security group rules, up to 120 rules can be added for each type.
The limits on outbound security group rules are the same as those on inbound rules.
For example, to add inbound IPv4 rules to a security group (Sg-A), you can refer to Table 4 for rules that meet the restrictions. Of these rules, rule A02 uses inconsecutive ports (TCP: 22,25,27) and security group Sg-B as the source. In this case, only one quota is occupied.
Table 4 Inbound security group rules Rule No.
Action
Type
Protocol & Port
Source
Rule A01
Allow
IPv4
All
Current security group: Sg-A
Rule A02
Allow
IPv4
TCP: 22,25,27
Another security group: Sg-B
Rule A03
Allow
IPv4
TCP: 80-82
IP address group: ipGroup-A
Rule A04
Allow
IPv4
TCP: 22-24,25
IP address: 192.168.0.0/16
- Traffic from load balancers is not restricted by network ACL and security group rules if:
Transfer Client IP Address is enabled for the listeners of a load balancer.
The load balancer can still forward traffic to backend servers, even if there is a rule that denies traffic from the load balancer to the backend servers.
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.
- 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 Working?