Cloud-native API Gateway supports IP-based access control through blacklists and whitelists. A blacklist blocks requests from specific IP addresses. A whitelist allows requests only from specific IP addresses. You can apply these policies at three levels -- global, domain name, and route -- for fine-grained control over which clients can reach your APIs.
How blacklists and whitelists interact
When policies exist at multiple levels, the gateway evaluates them as follows:
Blacklists take the union of all configurations. If an IP address appears in any blacklist at any level, the gateway blocks it.
Whitelists take the intersection of all configurations. An IP address must appear in every applicable whitelist to pass through.
For example, if a global whitelist allows 10.0.0.0/8 and a route-level whitelist allows 10.1.0.0/16, only addresses in 10.1.0.0/16 (the intersection) can access that route. Plan your policies carefully when combining blacklists and whitelists at different levels, because blacklist unions expand the blocked range while whitelist intersections narrow the allowed range.
Prerequisites
Before you begin, make sure that you have:
A Cloud-native API Gateway instance
The IP addresses or CIDR blocks you want to allow or block
Create an IP access control policy
Log on to the API Gateway console.
In the left-side navigation pane, click . In the top navigation bar, select a region.
On the Instance page, click the name of the target gateway instance.
In the left-side navigation pane, choose .
In the upper-left corner of the page, click Create.
On the Create page, configure the following parameters, and then click Save.
Parameter
Description
Enable
Toggles the policy on or off. The toggle is off by default. Turn it on if you want the policy to take effect immediately after creation.
Name
A name for the IP access control policy.
Remarks
Optional remarks for the policy.
Type
The type of access control. Whitelist (Allows Access from Specific IP Addresses) -- allows access only from trusted source IP addresses. Blacklist (Denies Access from Specific IP Addresses) -- blocks access from specific source IP addresses.
Effective Level
The network level at which the policy is enforced. See the following table for details.
Granularity
The scope of the policy. Global -- applies to the entire gateway instance. Domain Name -- applies to a specific domain name. Available only when Effective Level is set to Application Layer (HTTP/HTTPS). Routes -- applies to a specific route. Available only when Effective Level is set to Application Layer (HTTP/HTTPS).
IP Address/CIDR Block
The source IP addresses or CIDR blocks to allow or block. Enter one entry per line. Both individual IP addresses (for example,
192.168.1.1) and CIDR blocks (for example,10.0.0.0/8) are supported.
Effective level options
| Effective level | Behavior | When to use |
|---|---|---|
| Application Layer (HTTP/HTTPS) (default) | The gateway lets the client establish a TCP connection, then inspects the IP information in the HTTP request to decide whether to allow or block traffic. All three granularity levels (Global, Domain Name, and Routes) are available. | Standard API protection where connection-level overhead is acceptable. |
| Transport Layer (TCP/UDP) | The gateway checks the client IP address during the TCP handshake and immediately rejects connections from blocked IP addresses. Application-layer processing does not proceed. Only Global granularity is supported at this level. | High-security scenarios where blocked clients should not establish any connection. |
Verify the policy
After you save the policy, confirm that it works as expected:
On the Blacklist/Whitelist page, check that the new policy appears in the list. If you turned on the Enable toggle during creation, the status shows Enable. Otherwise, the status shows Close.
Send a test request from an IP address that should be blocked (for a blacklist) or allowed (for a whitelist), and check whether the gateway returns the expected response.
Modify or delete a policy
To modify or delete a policy, return to the Blacklist/Whitelist page and click the corresponding action in the policy list.
When you edit a policy, the Type, Effective Level, and Granularity fields cannot be changed. You can only modify the Enable status, Name, Remarks, and IP Address/CIDR Block. To change the type, effective level, or granularity, delete the existing policy and create a new one.