A cloud-native gateway and its backend services typically reside on nodes in different security groups. You can configure security group rules to allow the gateway to access the backend services.
Background
A security group acts as a virtual firewall that controls inbound and outbound traffic for its resources, such as ECS instances and elastic network interfaces (ENIs). A security group enhances security by providing stateful inspection and packet filtering. You can use security groups and security group rules to define security domains in the cloud. For more information, see Security group overview.
When you purchase a cloud-native gateway, you must select a VPC and a security group type. We recommend that you use the same security group type as your backend service. Based on your selection, the cloud-native gateway creates a corresponding managed security group to manage the gateway's instance nodes. Because the gateway and its backend services reside on nodes in different security groups, you must grant the gateway access to the necessary port range in the backend service's security group.
Step 1: Get the backend service security group
Upstream services associated with a cloud-native gateway are typically deployed in containers or on ECS instances. You can get the security group ID based on your deployment type.
Managed ACK cluster
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster. In the left navigation pane, click .
-
On the Node Pools page, click the target node pool, and then click the Basic Information tab to find the security group ID.
ACK Serverless cluster
Log on to the ACK console. In the left navigation pane, click Clusters.
-
On the Clusters page, click the name of the target cluster. On the Basic Information tab, find the security group ID.
ECS instance
Log in to the ECS console.
In the left-side navigation pane, choose .
-
On the Instance page, click the ECS instance where the backend service is deployed, and then click the Security Group tab to find the security group ID.
Step 2: Add a security group rule
-
Log on to the MSE console.
-
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
-
On the Gateways page, click the name of the target gateway. In the left-side navigation pane, click Overview, and then click the Security Group Authorization tab.
-
Click Add Security Group Rule. In the text box under the Security Group ID column, paste the security group ID that you obtained in Step 1 and select the corresponding security group.
-
Enter the Port Range for authorization, using the
start value/end valueformat.You can enter multiple port ranges. Press Enter after each entry.
-
Click Save.
The cloud-native gateway generates the corresponding rule.
This new rule also appears in the backend service node's security group.
Delete a security group rule
-
Log on to the MSE console.
-
In the left-side navigation pane, choose Cloud-native Gateway > Gateways. In the top navigation bar, select a region.
-
On the Gateways page, click the ID of the gateway.
-
In the left-side navigation pane, click Overview, and then click the Add Security Group Rule tab. In the Actions column for the rule you want to remove, click Delete, and then click OK.
By default, this action only deletes the authorization rule from the cloud-native gateway. To also delete the corresponding rule from the backend service's security group, you must select the Cascade Delete The Preceding Inbound Rules In This Security Group checkbox.
FAQ
Service inaccessible after authorization
You can troubleshoot the issue by following these steps:
-
Verify that you have authorized the correct security group for the node where your backend service is deployed.
For example, you might have authorized the security group for Node B, but the service is actually running on Node A.
-
Check if the target node belongs to multiple security groups.
If it does, we recommend authorizing each security group.
Sudden service access failure
You can troubleshoot the issue by following these steps:
-
Confirm that the service itself is running correctly.
You can use the
curlcommand from another node within the same security group to check if the service is reachable. -
Confirm whether the port exposed by your service has changed.
For example, if you authorized port 8080 for the cloud-native gateway but the service later changed to use port 8081, you must update the port in the security group authorization rule. To avoid this issue, consider specifying a wider port range, such as 1/65535, when you configure the authorization.