Help Center/ Identity and Access Management/ Best Practices/ IAM Custom Policy Examples

Updated on 2025-06-27 GMT+08:00

View PDF

IAM Custom Policy Examples

If system-defined policies cannot meet your requirements, you can create custom policies to implement more refined access control. You can refer to the following examples to customize policies for cloud services.

For more examples of other cloud services, see "Permissions Management" in the user guide of each cloud service.

Example Custom Policies for ECS

Example 1: Only allowing users to start, stop, and restart ECSs in batches

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:cloudServerFlavors:get",
                "ecs:cloudServers:reboot",
                "ecs:cloudServers:start",
                "ecs:cloudServers:get",
                "ecs:cloudServers:list",
                "ecs:cloudServers:stop"
            ]
        }
    ]
}

Example 2: Only allowing users to stop and delete ECSs in batches

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:cloudServers:get",
                "ecs:cloudServers:delete",
                "ecs:cloudServers:list",
                "ecs:cloudServers:stop"
            ]
        }
    ]
}

Example 3: Only allowing VNC login

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecs:cloudServerFlavors:get",
                "ecs:cloudServers:vnc",
                 "ecs:cloudServers:get",
                "ecs:cloudServers:list"
             ]
        }
    ]
}

Example 4: Denying ECS deletion
A policy with only "Deny" permissions must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

The following method can be used if you need to assign permissions of the ECSFullAccess policy to a user but you want to prevent the user from deleting ECSs. Create a custom policy for denying ECS deletion, and attach both policies to the group which the user belongs to. Then, the user can perform all operations on ECSs except deleting ECSs. The following is an example of a deny policy:
```
{ 
      "Version": "1.1", 
      "Statement": [ 
            { 
		  "Effect": "Deny", 
                  "Action": [ 
                        "ecs:cloudServers:delete" 
                  ] 
            } 
      ] 
}
```

Example Custom Policies for VPC

Example 1: Allowing users to create and view VPCs

{ 
    "Version": "1.1", 
    "Statement": [ 
        { 
            "Effect": "Allow", 
            "Action": [ 
                " 
                     vpc:vpcs:create 
                     vpc:vpcs:list 
                 " 
            ] 
        } 
    ] 
}

Example 2: Denying VPC deletion
A deny policy must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

The following method can be used if you need to assign permissions of the VPC FullAccess policy to a user but also forbid the user from deleting VPCs. Create a custom policy for denying VPC deletion, and assign both policies to the group the user belongs to. Then the user can perform all operations on VPC except deleting VPCs. The following is an example deny policy:
```
{ 
      "Version": "1.1", 
      "Statement": [ 
            { 
		  "Effect": "Deny", 
                  "Action": [ 
                        "vpc:vpcs:delete" 
                  ] 
            } 
      ] 
}
```

Example 3: Defining permissions for multiple services in a policy

A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "vpc:vpcs:create",
                "vpc:vpcs:update"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "ecs:servers:delete"
            ],
            "Effect": "Allow"
        }
    ]
}

Example 4: Allowing users to view associated resources
To allow users to view resources associated with a specific resource, you need to assign them permissions to query that resource and its associated resources. The following is an example policy containing actions for allowing users to view the servers, extended network interfaces, and supplementary network interfaces associated with a security group:
```
{  
    "Version": "1.1",  
    "Statement": [  
        {  
            "Effect": "Allow",  
            "Action": [  
                    "vpc:ports:get",
                    "vpc:securityGroups:get",  
                    "vpc:subNetworkInterfaces:list"  
                 "  
            ]  
        }  
    ]  
}
```

Example Custom Policies for ELB

Example 1: Allowing users to update a load balancer

{  
     "Version": "1.1",  
     "Statement": [  
         {  
             "Effect": "Allow",  
             "Action": [  
                 "elb:loadbalancers:put"  
             ]  
         }  
     ]  
 }

Example 2: Denying load balancer deletion
A deny policy must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

If you grant the system policy ELB FullAccess to a user but do not want the user to have the permission to delete load balancers defined in the policy, you can create a custom policy that rejects the deletion of load balancers and grant the ELB FullAccess and deny policies to the user, so that the user can perform all operations on ELB except deleting load balancers. The following is an example deny policy:
```
{  
       "Version": "1.1",  
       "Statement": [  
             {  
           "Effect": "Deny",  
                   "Action": [  
                         "elb:loadbalancers:delete"  
                   ]  
             }  
       ]  
 }
```

Example 3: Defining permissions for multiple services in a policy

A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elb:loadbalancers:get",
                "elb:loadbalancers:list",
                "elb:loadbalancers:delete",
                "ecs:cloudServers:delete"
            ]
        }
    ]
}

Example Custom Policies for CCE

Example 1: Creating a cluster named test

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cce:cluster:create"
            ]
        }
    ]
}

Example 2: Denying node deletion
A policy with only "Deny" permissions must be used with other policies. If the permissions assigned to a user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

If you want to grant the CCEFullAccess permission to a user but prevent them from deleting nodes (cce:node:delete), you can create a custom policy that denies node deletion. Then, attach this policy with the CCEFullAccess policy to the user. Since an explicit denial in any policy takes precedence over any allowances, the user will have permission to perform all operations on nodes except for deleting them. The following is an example of a deny policy:
```
{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "cce:node:delete"
            ]
        }
    ]
}
```

Example 3: Creating a custom policy containing multiple actions

A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing multiple actions:

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "ecs:cloudServers:resize",
                "ecs:cloudServers:delete",
                "ecs:cloudServers:delete",
                "ims:images:list",
                "ims:serverImages:create"
            ],
            "Effect": "Allow"
        }
    ]
}

Example Custom Policies for EVS

Example 1: Allowing users to create disks.

{
        "Version": "1.1",
        "Statement": [
                {
                        "Action": [
                                "evs:volumes:list",
                                "evs:volumes:get",
                                "evs:quotas:get",
                                "evs:volumeTags:list",
                                "evs:types:get",
                                "evs:volumes:create",
                                "ecs:cloudServerFlavors:get",
                                "ecs:cloudServers:list",
                                "bss:balance:view",
                                "bss:order:pay",
                                "bss:order:update"
                        ],
                        "Effect": "Allow"
                }
        ]
}

Example 2: Denying disk deletion
A policy with only "Deny" permissions must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

The following method can be used if you need to assign permissions of the EVS FullAccess policy to a user but you want to prevent the user from deleting EVS disks. Create a custom policy for denying disk deletion, and attach both policies to the group to which the user belongs. Then, the user can perform all operations on disks except deleting disks. The following is an example of a deny policy:
```
{
        "Version": "1.1",
        "Statement": [
                {
                        "Effect": "Deny",
                        "Action": [
                                "evs:volumes:delete"
                        ]
                }
        ]
}
```
- Example 3: Grant permissions to forcibly create encrypted disks.
  You can create a custom policy to force users to create only encrypted disks.
```
{
    "Version": "5.0",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "evs:volumes:create"
            ],
            "Condition": {
                "Bool": {
                    "evs:Encrypted": [
                        "false"
                    ]
                }
            }
        }
    ]
}
```
- Example 4: Grant permissions to forcibly create backups for disks.
  You can create a custom policy to force users to use cloud backup when creating disks.
  
  When forcible backup is configured and you are creating a yearly/monthly disk, you must choose an existing backup vault.
  
  Example policy:
```
{
    "Version": "5.0",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "evs:volumes:create"
            ],
            "Condition": {
                "Null": {
                    "cbr:VaultId": [
                        "true"
                    ]
                }
            }
        }
    ]
}
```

Example Custom Policies for CBR

Example 1: Allowing users to create, modify, and delete vaults

{
      "Version": "1.1",
      "Statement": [
            {
                  "Effect": "Allow",
                  "Action": [
                        "cbr:*:get*",
                        "cbr:*:list*",
                        "cbr:vaults:update",
                        "cbr:vaults:delete",
                        "cbr:vaults:create"
                  ]
            }
      ]
}

Example 2: Denying users to delete vaults and backups
A policy with only "Deny" permissions must be used in conjunction with other policies to take effect. If the permissions assigned to a user contain both "Allow" and "Deny", the "Deny" permissions take precedence over the "Allow" permissions.

If you need to assign permissions of the CBR FullAccess policy to a user but want to prevent the user from deleting vaults and backups, create a custom policy for denying vault and backup deletion, and attach both policies to the group to which the user belongs. In this way, the user can perform all operations on CBR except deleting vaults or backups. The following is an example deny policy:
```
{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "cbr:backups:delete",
                "cbr:vaults:delete"
            ]
        }
    ]
}
```

Example 3: Defining permissions for multiple services in a policy

A custom policy can contain the actions of multiple services that are of the global or project-level type. The following is an example policy containing actions of multiple services:

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cbr:vaults:create",
                "cbr:vaults:update",
                "cbr:vaults:delete"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "sfs:shares:createShare"
            ]
        }
    ]
}

Example Custom Policies for DLI

Example 1: Allow policies

Allow users to create tables across all databases in all regions:

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dli:database:createTable"
            ],
            "Resource": [
                "dli:*:*:database:*"
            ]
        }
    ]
}

Allow users to query column col in the table tb of the database db in the region where the user is located:

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dli:column:select"
            ],
            "Resource": [
                "dli:xxx:*:column:databases.db.tables.tb.columns.col"
            ]
        }
    ]
}

Allow users to query column col in the table tb of the database db:

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dli:column:select"
            ],
            "Resource": [
                "dli:*:*:column:databases.db.tables.tb.columns.col"
            ]
        }
    ]
}

Example 2: Deny policies

A deny policy must be used together with other policies. That is, a user can set a deny policy only after being assigned some operation permissions. Otherwise, the deny policy does not take effect.

If the permissions assigned to a user contain both Allow and Deny actions, the Deny actions take precedence over the Allow actions.

Deny users to create or delete databases, submit jobs (except the default queue), or delete tables.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "dli:database:createDatabase",
                "dli:database:dropDatabase",
                "dli:queue:submitJob",
                "dli:table:dropTable"
            ],
            "Resource": [
                "dli:*:*:database:*",
                "dli:*:*:queue:*",
                "dli:*:*:table:*"
            ]
        }
    ]
}

Deny users to submit jobs in the demo queue.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "dli:queue:submitJob"
            ],
            "Resource": [
                "dli:*:*:queue:queues.demo"
            ]
        }
    ]
}

Example 3: Tag authentication. You need to specify an action and bind it to a condition, and specify the key and value of g:ResourceTag.

Condition g: ResourceTag indicates a resource with the key=value tag. Only the operation on this resource contained in the policy action list is allowed.

The key is case insensitive. Fuzzy match for the value is not supported.

{
    "Version": "1.1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "dli:database:dropDatabase",
                "dli:table:select",
                "dli:database:createTable",
                "dli:table:dropTable"
            ],
            "Condition": {
                "StringEquals": {
                    "g:ResourceTag/key": [
                        "value"
                    ]
                }
            }
        }
    ]
}

Previous topic: Assigning Permissions to O&M Personnel Using IAM

Next topic: Delegating Other Accounts or Cloud Services for Resource Management