Container Compute Service:Custom policies for RAM users or RAM roles

Prerequisites

Before you begin, ensure that you have:

• Read Policy elements to understand policy structure and syntax

How RAM permissions and RBAC work together

ACS uses two separate authorization layers:

• RAM permissions (configured in the RAM console): control access to the ACS API — for example, which clusters a user can query, scale, or delete.

• RBAC permissions (configured in the ACS console): control access to Kubernetes resources within a cluster — for example, which namespaces or workloads a user can manage.

You must grant RAM permissions before you can grant RBAC permissions. At minimum, the RAM user or RAM role must have read-only access to a cluster before you can configure RBAC for it.

RAM permissions fall into two categories:

• Read permissions: view basic cluster information, such as cluster configurations and the kubeconfig file.

• Write permissions: manage a cluster, such as scaling, upgrading, and removing nodes.

The following policy grants read-only access to a specific cluster, which is the minimum required before performing RBAC authorization:

{
  "Statement": [
    {
      "Action": [
        "cs:Describe*"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<Cluster ID>"
      ]
    }
  ],
  "Version": "1"
}

After granting RAM permissions, use RBAC to grant the RAM user or RAM role permissions to manage cluster resources.

Step 1: Create a custom policy

ACS system policies are coarse-grained. If they don't meet your needs, create a custom policy for fine-grained access control — for example, to restrict permissions to a specific cluster or a specific set of operations.

1. Log on to the RAM console as a RAM administrator.

2. In the left-side navigation pane, choose Permissions > Policies.

3. On the Policies page, click Create Policy.

   

4. On the Create Policy page, click the JSON tab and enter the policy content. The following example grants read, list, describe, scale, and delete permissions on a specific cluster. Adjust the Action list to include only the permissions your use case requires — granting more permissions than necessary increases security risk:

   {
     "Statement": [{
       "Action": [
         "cs:Get*",
         "cs:List*",
         "cs:Describe*",
         "cs:ScaleCluster",
         "cs:DeleteCluster"
       ],
       "Effect": "Allow",
       "Resource": [
         "acs:cs:*:*:cluster/<Cluster ID>"
       ]
     }],
     "Version": "1"
   }

   Parameter	Description
   Action	The permissions to grant. Wildcard characters (*) are supported.
   Resource	The cluster or clusters the policy applies to. Replace <Cluster ID> with the actual cluster ID, such as cae93341766c843479ae986b3305xxxxx.

   Use the following Resource values based on scope:

   Scope	Value
   One cluster	"acs:cs:*:*:cluster/<Cluster ID>"
   Multiple clusters	One entry per cluster ID
   All clusters	"*"

5. Click OK. In the dialog box, enter the policy name and click OK to create the policy.

6. On the Policies page, search by name or description to find the policy.

Step 2: Attach the custom policy to a RAM user or RAM role

Attach a custom policy the same way you attach a system policy. For more information, see Attach a system policy to a RAM user or RAM role.

Grant permissions for non-cluster-specific API operations

Some ACS API operations are not scoped to a specific cluster — for example, DescribeEvents. To grant permissions for these operations, use "*" in the Resource field instead of a cluster ARN:

{
  "Statement": [
    {
      "Action": [
        "cs:Describe*"
      ],
      "Effect": "Allow",
      "Resource": [
        "*"
      ]
    }
  ],
  "Version": "1"
}