Permissions

You can use Identity and Access Management (IAM) to manage NAT Gateway permissions and control access to your resources. IAM provides identity authentication, permissions management, and access control.

You can create IAM users for your employees, and assign permissions to these users on a principle of least privilege (PoLP) basis to control their access to specific resource types. For example, you can create IAM users for software developers and assign specific permissions to allow them to use NAT Gateway resources but prevent them from being able to delete resources or perform any high-risk operations.

If your account does not require individual IAM users for permissions management, you can skip this section.

IAM is a free service. You only pay for the resources in your account. For more information about IAM, see What Is IAM?

NAT Gateway Permissions

New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and attach policies or roles to these groups. The users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.

NAT Gateway is a project-level service deployed and accessed in specific physical regions. When assigning NAT Gateway permissions to a user group, specify region-specific projects where the permissions will take effect. If you select All projects, the permissions will be granted for all region-specific projects. When accessing NAT Gateway, the users need to switch to a region where they have been authorized to use this service.

You can grant users permissions by using roles and policies.

Roles: A type of coarse-grained authorization mechanism that provides only a limited number of service-level roles. When using roles to grant permissions, you also need to assign dependency roles. However, roles are not an ideal choice for fine-grained authorization and secure access control.

Policies: A type of fine-grained authorization mechanism that defines permissions required to perform operations on specific cloud resources under certain conditions. This mechanism allows for more flexible policy-based authorization for more secure access control. For example, the account administrator can grant users only permission to manage a certain type of NAT gateways and SNAT rules. Most policies define permissions based on APIs. For the API actions supported by NAT Gateway, see Permissions Policies and Supported Actions.

Table 1 lists all the system-defined roles and policies supported by NAT Gateway.

**Table 1** System-defined roles and policies supported by NAT Gateway
Policy Name	Description	Type
NAT FullAccess	All operations on NAT Gateway resources.	System-defined policy
NAT ReadOnlyAccess	Read-only permissions for all NAT Gateway resources.	System-defined policy
NAT Administrator	All operations on NAT Gateway resources. To be granted this permission, users must also have the Tenant Guest permission.	System-defined role

Table 2 lists the common operations supported by each NAT Gateway system policy or role. Select the policies or roles as required.

**Table 2** Common operations supported by each system-defined policy or role of NAT Gateway
Operation	NAT FullAccess	NAT ReadOnlyAccess	NAT Gateway Administrator
Creating a NAT gateway	√	x	√
Querying NAT gateways	√	√	√
Querying NAT gateway details	√	√	√
Updating a NAT gateway	√	x	√
Deleting a NAT gateway	√	x	√
Adding an SNAT rule	√	x	√
Viewing an SNAT rule	√	√	√
Modifying an SNAT rule	√	x	√
Deleting an SNAT rule	√	x	√
Adding a DNAT rule	√	x	√
Viewing a DNAT rule	√	√	√
Modifying a DNAT rule	√	x	√
Deleting a DNAT rule	√	x	√
Deleting DNAT rules in one batch	√	x	√
Importing DNAT rules using templates	√	x	√
Exporting DNAT rules using templates	√	√	√
Creating a transit subnet	√	x	√
Querying transit subnets	√	√	√
Querying details about a transit subnet	√	√	√
Modifying a transit subnet	√	x	√
Deleting a transit subnet	√	x	√
Assigning a transit IP address	√	x	√
Querying a transit IP address	√	√	√
Releasing a transit IP address	√	x	√

Note the following when creating a NAT gateway:
- To create a yearly/monthly NAT gateway, you also need to obtain the BSS Administrator permissions of the Billing Center. For details, see the Billing Center User Guide.

Note the following when creating a DNAT rule:
- If you set Instance Type to Server and select an ECS, you also need to obtain the ECS ReadOnlyAccess permissions or the fine-grained permissions for actions ecs:cloudServers:get and ecs:cloudServers:list. For details, see the Elastic Cloud Server API Reference.
- If you set Instance Type to Server and select a BMS, you also need to obtain the BMS ReadOnlyAccess permissions or the fine-grained permissions for actions bms:servers:get and bms:servers:list. For details, see the Bare Metal Server API Reference.
- If you create a DNAT rule on a private NAT gateway and select Load balancer for Instance Type, you need to obtain the ELB ReadOnlyAccess permissions or the fine-grained permissions for actions elb:loadbalancers:get and elb:loadbalancers:list. For details, see the Elastic Load Balance API Reference.
- After a DNAT rule is created, add a security group rule to allow the Internet to access servers for which the DNAT rule is configured. Otherwise, the DNAT rule does not take effect. Obtain the VPC FullAccess permissions or the fine-grained permissions for action vpc:securityGroups:create by referring to the Virtual Private Cloud API Reference.

To view metrics, obtain the CES ReadOnlyAccess permissions. For details, see the Cloud Eye API Reference.
To view access logs, obtain the LTS ReadOnlyAccess permissions. For details, see the Log Tank Service API Reference.
To query predefined tags, obtain the TMS Administrator permissions. For details, see the Tag Management Service API Reference.