Custom policies can be created to supplement the system-defined policies of CSS. For the actions supported for custom policies, see Permissions Policies and Supported Actions.

You can create custom policies in either of the following ways:

• Visual editor: Select cloud services, actions, resources, and request conditions without the need to know policy syntax.
• JSON: Edit JSON policies from scratch or based on an existing policy.

For details, see Creating a Custom Policy. The following section contains examples of common CSS custom policies.

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "ces:*:get*",
                "ces:*:list*"
            ],
            "Effect": "Allow"
        }
    ]
}

If a user account has enabled the enterprise project function:

• When the CSS FullAccess permission is granted to the account, all enterprise projects have the CSS FullAccess permission even if only an enterprise project is configured with the CSS ReadOnlyAccess permission.
• If the CSS FullAccess permission is granted to an enterprise project, all users in the enterprise project can have this permission. For example, if the CSS FullAccess permission is granted to an enterprise project by default, all users in this enterprise project can read and write clusters in this enterprise project.

Example 2: Granting users the CSS ReadOnlyAccess permission, that is, allowing users to only read CSS resources To view cluster monitoring information, a user must have the read-only permission of Cloud Eye.

1. Grant the CSS ReadOnlyAccess permission to a user.

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "css:*:get*",
                "css:*:list*",
                "vpc:securityGroups:get",
                "vpc:securityGroupRules:get",
                "vpc:vpcs:list",
                "vpc:privateIps:list",
                "vpc:ports:get",
                "vpc:quotas:list",
                "vpc:subnets:get",
                "ecs:cloudServerFlavors:get",
                "ecs:quotas:get",
                "evs:types:get",
                "evs:quotas:get"              
            ],
            "Effect": "Allow"
        }
    ]
}

2. (Optional) Grant a user the permission to view cluster monitoring information.

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "ces:*:get*",
                "ces:*:list*"
            ],
            "Effect": "Allow"
        }
    ]
}

If a user account has enabled the enterprise project function:

• If the CSS ReadOnlyAccess permission is granted to the account in IAM and the CSS FullAccess permission is granted to an enterprise project, users in this enterprise project can read clusters in all enterprise projects but can write only clusters in the enterprise project with the CSS FullAccess permission. For example, if the CSS FullAccess permission is granted to an enterprise project by default, users in this enterprise project can read clusters in all enterprise projects, but can write only clusters in the enterprise project with the CSS FullAccess permission.
• If the CSS ReadOnlyAccess permission is granted to the account in IAM but no authorization is configured for any enterprise project, users can only read clusters in this enterprise project. For example, if the CSS ReadOnlyAccess permission is granted to an enterprise project by default, users in this enterprise project can only read clusters in the enterprise project with the CSS ReadOnlyAccess permission.

{
    "Version": "1.1",
    "Statement": [
        {
            "Action": [
                "css:cluster:create",
                "vpc:securityGroups:get",
                "vpc:securityGroups:create",
                "vpc:securityGroups:delete",
                "vpc:securityGroupRules:get",
                "vpc:securityGroupRules:create",
                "vpc:securityGroupRules:delete",
                "vpc:vpcs:list",
                "vpc:privateIps:list",
                "vpc:ports:get",
                "vpc:ports:create",
                "vpc:ports:update",
                "vpc:ports:delete",
                "vpc:quotas:list",
                "vpc:subnets:get",
                "ecs:cloudServerFlavors:get",
                "ecs:serverInterfaces:use",
                "ecs:cloudServers:addNics",
                "ecs:quotas:get",
                "evs:types:get",
                "evs:quotas:get"
            ],
            "Effect": "Allow"
        }
    ]
}

Example 2: Denying cluster 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 CSS Admin policy to a user but you want to prevent the user from deleting clusters. Create a custom policy for denying cluster deletion, and attach both policies to the group to which the user belongs. Then, the user can perform all operations on CSS except deleting clusters. The following is an example of a deny policy:

{ 
      "Version": "1.1", 
      "Statement": [ 
            { 
		  "Effect": "Deny", 
                  "Action": [ 
                        "css:cluster: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": [
                "ecs:cloudServers:resize",
                "ecs:cloudServers:delete",
                "ecs:cloudServers:delete",
                "css:cluster:restart",
                "css:*:get*",
                "css:*:list*"
            ],
            "Effect": "Allow"
        }
    ]
}