Network ACL for AccessKeys-Resource Access Management(RAM)-阿里云帮助中心

Policy types

RAM provides the following two types of network ACLs for AccessKeys:

Account-level network ACL

This policy applies to all AccessKeys within your Alibaba Cloud account, including the root account AccessKey and RAM user AccessKeys. Use this policy type to apply a uniform set of network rules to all AccessKeys in your account.
AccessKey-level network ACL

This policy applies to a single AccessKey that belongs to either a root account or a RAM user. Use this policy type to define specific rules for an individual AccessKey or to create an exception to an existing account-level policy.

An AccessKey-level ACL takes precedence over an account-level ACL. If an AccessKey-level ACL is configured for an AccessKey, the account-level ACL does not apply to that AccessKey.

The following flowchart shows how network ACLs are evaluated:

Usage notes

Network ACLs for AccessKeys apply only to permanent AccessKeys. They do not affect API calls made with temporary credentials (STS).
To restrict network access for console sign-ins, use a logon mask. For more information, see Configure logon masks.
Before you apply an ACL to your production environment, test it with a new or non-critical AccessKey. This helps prevent misconfigurations that could disrupt your business operations.
If an application deployed on Alibaba Cloud calls another cloud service over the public internet, configure a public network rule. If it calls a service through a private network, such as a Virtual Private Cloud (VPC) endpoint, configure a VPC rule.

Limitations

Network ACLs for AccessKeys apply to all cloud services except for ApsaraMQ for RocketMQ, ApsaraMQ for RabbitMQ, ApsaraMQ for MQTT, EventBridge, Message Service (MNS), Cloud Monitor (for reporting event monitoring data over HTTP), and Hologres. The respective product teams will announce when this feature becomes available for the unsupported services.
An Alibaba Cloud account and a single AccessKey can each have up to eight network ACLs. You can add at most one public network ACL.
Each ACL can contain up to 50 IP addresses or CIDR blocks.

ACL configuration

Before you configure an ACL, review your AccessKey audit logs in ActionTrail and consult your organization's network information to compile a list of trusted network addresses. This ensures that your ACL is accurate and complete.

Account-level ACL configuration

Log on to the RAM console as a RAM administrator.
On the Settings page, in the Network Access Control section, click Modify to the right of Allowed source network address while calling APIs by AccessKey.
In the Account-level Network Access Control panel, configure the public network and VPC rules, enable the policy, and then click Submit.

The network ACL does not apply to the following products: ApsaraMQ for RocketMQ, ApsaraMQ for RabbitMQ, ApsaraMQ for MQTT, EventBridge, Message Service (MNS), Cloud Monitor (for reporting event monitoring data over HTTP), and Hologres. Before you create an ACL, check the historical source IP addresses in the AccessKey audit logs.
- Policy Status: Select Enable to activate the ACL.
- Public Network ACL: Click Add Public Network Statement and enter public IP addresses or CIDR blocks. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a public network rule, all access from public IP addresses is denied. If you click Allow All Public Network Access, the system adds a rule with the CIDR block 0.0.0.0/0 or ::/0 to allow access from all public IP addresses.
- VPC Network ACL: Click Add VPC (Virtual Private Cloud) Statement, then enter a VPC ID and the IP addresses or CIDR blocks within that VPC. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a VPC rule, all access from IP addresses within VPCs is denied. If you click Allow All VPC Network Access, the system adds a rule with the VPC ID AllowAllVPC and the CIDR block 0.0.0.0/0 or ::/0. This allows access from all IP addresses within all VPCs across all accounts.
Note
You can enter multiple IP addresses or CIDR blocks in a single rule. Separate entries with spaces, commas (,), or semicolons (;).
In the Confirm Submission dialog box, enter your account ID and click OK.

Important
After you submit the ACL, it may take a few minutes to take effect. An account-level ACL does not apply to an AccessKey with a configured AccessKey-level ACL.

AccessKey-level ACL for RAM users

Log on to the RAM console as a RAM administrator.
In the left-side navigation pane, choose Identities > Users.
On the Users page, click the name of the target RAM user.
On the Authentication tab, in the AccessKey section, find the target AccessKey and click Network Access Control in the Actions column.

If an AccessKey is old (for example, created five months ago), a Rotation Recommended tag appears in the Created column.
In the AccessKey-level Network Access Control panel, configure the public network and VPC rules, enable the policy, and then click Submit.

This ACL does not apply to the following products: ApsaraMQ for RocketMQ, ApsaraMQ for RabbitMQ, ApsaraMQ for MQTT, EventBridge, Message Service (MNS), Cloud Monitor (for reporting event monitoring data over HTTP), and Hologres. Before you create an ACL, check the AccessKey audit logs.
- Policy Status: Select Enable to activate the ACL.
- Public Network ACL: Click Add Public Network Statement and enter public IP addresses or CIDR blocks. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a public network rule, all access from public IP addresses is denied. If you click Allow All Public Network Access, the system adds a rule with the CIDR block 0.0.0.0/0 or ::/0 to allow access from all public IP addresses.
- VPC Network ACL: Click Add VPC (Virtual Private Cloud) Statement, then enter a VPC ID and the IP addresses or CIDR blocks within that VPC. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a VPC rule, all access from IP addresses within VPCs is denied. If you click Allow All VPC Network Access, the system adds a rule with the VPC ID AllowAllVPC and the CIDR block 0.0.0.0/0 or ::/0. This allows access from all IP addresses within all VPCs across all accounts.
Note
You can enter multiple IP addresses or CIDR blocks in a single rule. Separate entries with spaces, commas (,), or semicolons (;).
In the Confirm Submission dialog box, enter the AccessKey ID and click OK.

Important
After you submit the ACL, it may take a few minutes to take effect. An account-level ACL does not apply to an AccessKey with a configured AccessKey-level ACL.

AccessKey-level ACL for the root account

Log on to the Alibaba Cloud Management Console with your root account.
Hover over your profile picture in the upper-right corner and click AccessKey Management.
In the We do not recommend using the AccessKey pair of an Alibaba Cloud account dialog box, select I understand the risks of using the AccessKey pair of an Alibaba Cloud account and click Use the AccessKey Pair of the Alibaba Cloud Account.
Find the target AccessKey and click Network Access Control in the Actions column.
In the AccessKey-level Network Access Control panel, configure the public network and VPC rules, enable the policy, and then click Submit.
- Policy Status: Select Enable to activate the ACL.
- Public Network ACL: Click Add Public Network Statement and enter public IP addresses or CIDR blocks. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a public network rule, all access from public IP addresses is denied. If you click Allow All Public Network Access, the system adds a rule with the CIDR block 0.0.0.0/0 or ::/0 to allow access from all public IP addresses.
- VPC Network ACL: Click Add VPC (Virtual Private Cloud) Statement, then enter a VPC ID and the IP addresses or CIDR blocks within that VPC. Both IPv4 and IPv6 formats are supported.
  
  If you do not add a VPC rule, all access from IP addresses within VPCs is denied. If you click Allow All VPC Network Access, the system adds a rule with the VPC ID AllowAllVPC and the CIDR block 0.0.0.0/0 or ::/0. This allows access from all IP addresses within all VPCs across all accounts.
Note
You can enter multiple IP addresses or CIDR blocks in a single rule. Separate entries with spaces, commas (,), or semicolons (;).
In the Confirm Submission dialog box, enter the AccessKey ID and click OK.

Important
After you submit the ACL, it may take a few minutes to take effect. An account-level ACL does not apply to an AccessKey with a configured AccessKey-level ACL.

Configuration examples

Scenario	ACL configuration
No network access restrictions for any AccessKey.	Set the Disable of all account-level and AccessKey-level ACLs to Disable. The content of the ACL does not matter.
Allow API calls from all public IP addresses.	In an account-level or AccessKey-level ACL, add a public network rule for the CIDR block `0.0.0.0/0` or `::/0`.
Allow API calls from all IP addresses in any VPC across all accounts.	In an account-level or AccessKey-level ACL, add a VPC rule with the VPC ID `AllowAllVPC` and the CIDR block `0.0.0.0/0` or `::/0`.
Deny all API calls from public IP addresses.	In an account-level or AccessKey-level ACL, set the Enable to Enable, but do not add any public network rules.
Deny all API calls from IP addresses in VPCs.	In an account-level or AccessKey-level ACL, set the Enable to Enable, but do not add any VPC rules.
An account-level ACL is active, but a specific AccessKey needs to accept calls from all public and VPC IP addresses.	Enable an AccessKey-level ACL for the specific AccessKey with the following rules: Public Network Policy: Add a rule for the CIDR block `0.0.0.0/0` or `::/0`. VPC Network Policy: Add a rule with the VPC ID `AllowAllVPC` and the CIDR block `0.0.0.0/0` or `::/0`.
Allow all AccessKeys in an Alibaba Cloud account to call Alibaba Cloud APIs from a specific public IP address (for example, `203.0.113.1`) and from a specific CIDR block (for example, `192.168.0.0/16`) within a specific VPC (for example, `vpc-m5ekxe1zi8zwgqrtc****`).	Enable an account-level ACL with the following rules: Public Network Policy: Add a rule that specifies the IP address `203.0.113.1`. VPC Network Policy: Add a rule that specifies the VPC ID `vpc-m5ekxe1zi8zwgqrtc****` and the CIDR block `192.168.0.0/16`. For more information, see Account-level ACL configuration.
Allow a specific AccessKey to call Alibaba Cloud APIs from a specific public IP address (for example, `203.0.113.1`) and from a specific CIDR block (for example, `192.168.0.0/16`) within a specific VPC (for example, `vpc-m5ekxe1zi8zwgqrtc****`).	Enable an AccessKey-level ACL for the specific AccessKey with the following rules: Public Network Policy: Add a rule that specifies the IP address `203.0.113.1`. VPC Network Policy: Add a rule that specifies the VPC ID `vpc-m5ekxe1zi8zwgqrtc****` and the CIDR block `192.168.0.0/16`. After you enable the AccessKey-level ACL, the account-level ACL no longer applies to this AccessKey. For more information, see AccessKey-level ACL for RAM users and AccessKey-level ACL for the root account.

FAQ

Identifying trusted IP addresses

Review historical source IP addresses in ActionTrail

You can use the audit logs in ActionTrail to query and analyze the source IP addresses from past successful calls. The steps are as follows:

If you have configured a trail to deliver events to Log Service (SLS): In the ActionTrail console, go to the Trails page, open the trail details, and click the Logstore name to open the Log Service console. You can then search for the previous source IP addresses (event.sourceIpAddress) or VPC IDs (event.vpcId) for a specific AccessKey (field event.userIdentity.accessKeyId). For more information, see Query events in the SLS or OSS console.

Sample query statement:

* | SELECT "event.userIdentity.accessKeyId" AS access_key_id, "event.sourceIpAddress" AS source_ip_address, "event.vpcId" AS vpc_id FROM log WHERE "event.userIdentity.accessKeyId" = 'LTAI****************'
If you have not configured a trail to deliver events to Log Service (SLS): In the ActionTrail console, go to the AccessKey Audit page, enter an AccessKey ID, and view the source IP address of each cloud service call in the call records. For more information, see Query AccessKey logs.

ActionTrail can query only supported cloud service audit events. For data events that are not supported by ActionTrail, you need to use the native audit features of the corresponding cloud service.

Query network configurations

Applications deployed on Alibaba Cloud

If your applications are deployed on Alibaba Cloud services such as ECS or container services, you can directly query the public IP address, Virtual Private Cloud (VPC) ID, and private CIDR block bound to the resource.

If your application calls the public endpoint of a cloud service, the call is made over the public internet, and the source IP address is the egress public IP address or the public IP address of a NAT gateway. If your application calls the VPC endpoint of a cloud service, the call is made over a private network, and the source IP address is a private IP address within the VPC.

Calls between cloud services

When one Alibaba Cloud service (Service A) transfers data to another (Service B), the source IP of the call might be an internal IP address of Service A. In ActionTrail records, this event source can appear as a cloud service address or "internal". For these inter-service calls, use service roles or other credential-free solutions instead of AccessKeys.

The following are configuration references for some inter-service calls:

DataWorks: For the IP address ranges used when calling MaxCompute for data analysis, see Data analysis whitelist. For IP address ranges that might be used for metadata collection, see Whitelist configuration required when the data source for metadata collection has whitelist access control.
Log Service (SLS): To transfer logs to other Alibaba Cloud accounts through data processing, we recommend using a RAM role instead of an AccessKey. For guidance on this, see create and use a RAM role to transfer data within the same account.
Application Real-Time Monitoring Service (ARMS): For cross-account access, we recommend that you use a RAM role.

Dynamic IP addresses

When cloud resources are elastically scaled or automatically reconfigured, their IP addresses can change dynamically. You must promptly add the new IP addresses to the network ACL.
Function Compute: By default, Function Compute uses dynamic public IP addresses, so a fixed IP address cannot be guaranteed. You can configure a static public IP address for your function.

Applications deployed outside Alibaba Cloud

You must manually determine the egress IP addresses of your external application environments.

Office network IP addresses

If you use an AccessKey for local development and debugging, contact your company's network administrator to obtain the egress IP address of your office network.

Handling unexpected API rejections

Symptoms

After a network ACL for AccessKeys takes effect, it rejects calls from source IP addresses not on the allowlist. Common error messages include:

Message: The specified parameter "AccessKeyId.AccessPolicyDenied" is not valid.

Message: code: 400, Specified access key denied due to access policy.

Solution

If a network ACL unexpectedly rejects an API call, try the following steps to resolve the issue:

Check whether the restricted AccessKey has an AccessKey-level ACL configured.
- If yes, modify the AccessKey-level ACL to add the source IP address to the allowlist.
- If no, proceed to the next step.
As a RAM administrator, check and modify the account-level ACL to add the source IP address to the allowlist.
If the problem persists, the source IP address you are trying to add might be incorrect. Verify and obtain the correct source IP address.

You can use ActionTrail to help query the historical source IP addresses for the AccessKey. For more information, see Review historical source IP addresses in ActionTrail.