Best practices for role-based authorization - Container Compute Service

Container Compute Service (ACS) uses a two-layer authorization model: Resource Access Management (RAM) controls access to cloud resources, and Role-Based Access Control (RBAC) controls access to Kubernetes resources within a cluster. This topic covers authorization best practices for five types of roles: enterprise resource managers, Kubernetes cluster administrators, cluster and application O&M engineers, application developers, and permission administrators.

How the authorization system works

ACS clusters are a type of Container Service for Kubernetes (ACK) Serverless cluster. All cluster O&M operations—creating, viewing, and deleting clusters; managing RBAC; and monitoring logs and events—go through the ACK API. Any principal that needs to manage clusters must have the relevant ACK API permissions granted through RAM.

RBAC authorization then governs what that principal can do inside the cluster: create, delete, modify, or view Kubernetes resources such as workloads (Deployment, StatefulSet, Job, CronJob, pod, ReplicaSet, HorizontalPodAutoscaler (HPA)), network resources (Service, Ingress, NetworkPolicy), storage resources (persistent volume (PV), persistent volume claim (PVC), StorageClass), and namespace-level resources (namespace, ConfigMap, Secret).

Important

Always grant RAM permissions before granting RBAC permissions.

Find your scenario

Identify which role you need to authorize, then go to the corresponding section:

Role	When you need this	Go to
O&M engineer	The principal needs to manage ACS clusters (create, upgrade, delete) and operate on application resources inside them.	Scenario 1: O&M engineer
Application developer	The principal needs to operate on Kubernetes resources inside a cluster but does not manage the cluster itself.	Scenario 2: Application developer
Permission administrator	The principal needs to manage RBAC authorization for other RAM users or RAM roles.	Scenario 3: Permission administrator

System default policies

ACS provides the following system authorization policies for quick setup.

Important

System default policies grant broad permissions—read or write access to all OpenAPI operations of ACK and ACS. Use these policies with caution, and prefer custom policies scoped to a specific cluster ARN when you need narrower permissions.

Policy	What it grants
AliyunAccFullAccess	Full management permissions for ACS
AliyunAccReadOnlyAccess	Read-only permissions for ACS
AliyunCSFullAccess	Full management permissions for ACK, including all ACS clusters
AliyunCSReadOnlyAccess	Read-only permissions for ACK, including all ACS clusters

AliyunAccFullAccess

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

AliyunAccReadOnlyAccess

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

AliyunCSFullAccess

{
    "Version": "1",
    "Statement": [
        {
            "Action": "cs:*",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ram:PassRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:Service": "cs.aliyuncs.com"
                }
            }
        }
    ]
}

AliyunCSReadOnlyAccess

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

Predefined RBAC roles

ACK provides four predefined cluster-level RBAC roles. After you attach a predefined role, ACS automatically creates a ClusterRoleBinding in the cluster that maps the RAM user or RAM role to that role.

The Alibaba Cloud account (root account) and the cluster creator are bound to the cluster-admin role by default and have full access to all Kubernetes resource objects in the cluster.

Role	What it grants	What it excludes
Administrator	Read and write on all resources in all namespaces	—
O&M engineer	Read and write on console-visible Kubernetes resources in all namespaces; read-only on nodes, PVs, namespaces, and resource quotas	Write access to cluster-level infrastructure (nodes, PVs). This restriction prevents accidental deletion of shared infrastructure.
Developer	Read and write on console-visible Kubernetes resources in all or selected namespaces	Access to nodes, PVs, namespaces, or resource quotas. Developers can manage application workloads without affecting cluster infrastructure.
Restricted user	Read-only on console-visible Kubernetes resources in all or selected namespaces	Write access to any resource

Authorization best practices

Scenario 1: O&M engineer

An O&M engineer manages ACS clusters and operates on application resources inside them. This role requires both RAM authorization and RBAC authorization.

Step 1: Grant RAM permissions

Attach one of the following system policies through the RAM console, or create a custom policy for fine-grained control.

AliyunCSFullAccess — read and write access to all ACK OpenAPI operations
AliyunCSReadOnlyAccess — read-only access to all ACK OpenAPI operations

For instructions, see RAM consoleGrant permissions to a RAM user and Grant permissions to a RAM role.

Important

Both system policies apply to all ACK clusters, including ACS clusters. For cluster-specific permissions, create a custom policy scoped to acs:cs:*:*:cluster/<yourclusterID>.

The following example grants the permissions needed to manage a specific ACS cluster, including creating clusters, viewing cluster details, managing addons, and monitoring logs.

{
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "acc:DescribeCommodityStatus",
                "acc:CheckServiceRole",
                "acc:DescribeCloudProducts",
                "acc:DescribeRegions",
                "acc:DescribeZones",
                "acc:GetInstancePrice",
                "acc:RecommendZones"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "bssapi:GetPayAsYouGoPrice",
            "Resource": "*"
        },
        {
            "Action": "ecs:DescribePrice",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "ram:GetRole",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
            "cs:CreateCluster",
            "cs:DescribeAddons",
            "cs:DescribeUserQuota",
            "cs:DescribeTasks",
            "cs:ListClusterAddonInstances"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                "cs:GetClusters",
                "cs:DescribeClustersV1",
                "cs:DescribeClusterUserKubeconfig",
                "cs:DescribeClusterResources",
                "cs:DescribeUserQuota",
                "cs:DescribeClusterLogs",
                "cs:ModifyCluster",
                "cs:UpgradeCluster",
                "cs:GetUpgradeStatus",
                "cs:ResumeUpgradeCluster",
                "cs:PauseClusterUpgrade",
                "cs:CancelClusterUpgrade",
                "cs:InstallClusterAddons",
                "cs:UpgradeClusterAddons",
                "cs:DescribeClusterAddonsUpgradeStatus",
                "cs:UnInstallClusterAddons",
                "cs:DeleteCluster",
                "cs:DescribeClusterDetail",
                "cs:GetClusterAuditProject",
                "cs:DescribeClusterAddonsVersion",
                "cs:DescribeClusterTasks",
                "cs:DescribeClusterEvents",
                "cs:DescribeEvents",
                "cs:ListClusterReportSummary",
                "cs:GetClusterBasicInfo",
                "cs:ListReportTaskRule",
                "cs:CreateReportTaskRule",
                "cs:CheckControlPlaneLogEnable",
                "cs:CreateClusterCheck"
            ],
            "Effect": "Allow",
            "Resource": "acs:cs:*:*:cluster/<yourclusterID>"
        },
        {
            "Action": [
                 "cs:CheckServiceRole",
                 "cs:DescribeKubernetesVersionMetadata"
            ],
            "Effect": "Allow",
            "Resource": "acs:cs:*:*:cluster/*"
        },
        {
            "Action": [
                 "log:ListProject"
            ],
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": [
                 "vpc:ListEnhanhcedNatGatewayAvailableZones",
                 "vpc:DescribeEipAddresses",
                 "vpc:DescribeVSwitches"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "1"
}

Replace <yourclusterID> with the ID of your ACS cluster.

For ACK OpenAPI details, see \[Product Change\] Announcement on the optimization of OpenAPI authentication for Container Service and API overview.

Step 2: Grant RBAC permissions

In the Container Compute Service console, click Authorizations in the left navigation pane.
On the RAM Users or RAM Roles tab, find the authorization object and click Modify Permissions.
In the dialog box, click Add Permissions, set the role for the target cluster and namespace to O&M engineer, and click Submit.

For fine-grained RBAC control, create a custom ClusterRole (see RBAC), then on the Authorizations page select Custom and choose the ClusterRole name from the drop-down list. For more information, see Create a custom RBAC authorization policy.

The predefined O&M engineer role (cs:ops) grants the following ClusterRole permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cs:ops
rules:
- apiGroups: [""]
  resources:  ["pods", "pods/attach", "pods/exec", "pods/portforward", "pods/proxy"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: [""]
  resources:  ["configmaps", "endpoints", "persistentvolumeclaims", "replicationcontrollers", "replicationcontrollers/scale", "secrets", "serviceaccounts", "services", "services/proxy"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: [""]
  resources:  ["bindings", "events", "limitranges", "namespaces/status", "replicationcontrollers/status", "pods/log", "pods/status", "resourcequotas", "resourcequotas/status", "componentstatuses"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:  ["namespaces", "nodes", "persistentvolumes"]
  verbs: ["get", "list", "watch", "patch"]
- apiGroups: ["coordination.k8s.io"]
  resources:  ["leases"]
  verbs: ["get"]
- apiGroups: ["apps"]
  resources:  ["daemonsets", "deployments", "deployments/rollback", "deployments/scale", "replicasets", "replicasets/scale", "statefulsets"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["autoscaling"]
  resources:  ["horizontalpodautoscalers"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["batch"]
  resources:  ["cronjobs", "jobs"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["extensions"]
  resources:  ["daemonsets", "deployments", "deployments/rollback", "deployments/scale","ingresses","replicasets", "replicasets/scale", "replicationcontrollers/scale"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["servicecatalog.k8s.io"]
  resources:  ["clusterserviceclasses", "clusterserviceplans", "clusterservicebrokers", "serviceinstances", "servicebindings"]
  verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["servicecatalog.k8s.io"]
  resources:  ["clusterservicebrokers/status", "clusterserviceclasses/status", "clusterserviceplans/status", "serviceinstances/status", "serviceinstances/reference", "servicebindings/status",]
  verbs: ["update"]
- apiGroups: ["storage.k8s.io"]
  resources:  ["storageclasses"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["alicloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["policy"]
  resources:  ["poddisruptionbudgets"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["networking.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["config.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["rbac.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["istio.alibabacloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["authentication.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["log.alibabacloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["monitoring.kiali.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["kiali.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["apiextensions.k8s.io"]
  resources: ["customresourcedefinitions"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["serving.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["eventing.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["messaging.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["sources.eventing.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["tekton.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["alert.alibabacloud.com"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]

Scenario 2: Application developer

An application developer operates on Kubernetes resources inside a cluster but does not manage the cluster itself. This role requires only read-only RAM permissions on the specific cluster, plus RBAC authorization.

Important

Before granting RBAC permissions, the authorization object must have at least read-only RAM permissions on the target cluster. Do not use AliyunCSReadOnlyAccess for this purpose—that policy grants read-only access to all ACK clusters and is broader than needed. Use a custom policy that specifies the cluster ARN instead.

Step 1: Grant RAM permissions

Create a custom policy scoped to the specific cluster ARN and attach it to the RAM user or RAM role through the RAM console. For instructions, see Grant RAM permissions to a RAM user or RAM role.

{
  "Statement": [
   {
        "Effect": "Allow",
        "Action": [
            "acc:DescribeCommodityStatus",
            "acc:CheckServiceRole",
            "acc:DescribeCloudProducts",
            "acc:DescribeRegions",
            "acc:DescribeZones",
            "acc:GetInstancePrice",
            "acc:RecommendZones"
           ],
            "Resource": "*"
    },
    {
         "Effect": "Allow",
         "Action": "bssapi:GetPayAsYouGoPrice",
         "Resource": "*"
    },
    {
      "Action": [
        "cs:Get*",
        "cs:List*",
        "cs:Check*",
        "cs:Describe*"
      ],
      "Effect": "Allow",
      "Resource": [
        "acs:cs:*:*:cluster/<yourclusterID>"
      ]
     },
     {
       "Action": [
          "vpc:ListEnhanhcedNatGatewayAvailableZones",
          "vpc:DescribeEipAddresses"
       ],
          "Effect": "Allow",
          "Resource": "*"
      }
  ],
  "Version": "1"
}

Replace <yourclusterID> with the ID of your ACS cluster.

Step 2: Grant RBAC permissions

In the Container Compute Service console, click Authorizations in the left navigation pane.
On the RAM Users or RAM Roles tab, find the authorization object and click Modify Permissions.
In the dialog box, click Add Permissions, set the role for the target cluster and namespace to Developer, and click Submit.

After you attach the predefined role, ACS automatically creates a ClusterRoleBinding for the authorization object. The predefined developer role (cs:ns:dev) grants the following ClusterRole permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cs:ns:dev
rules:
- apiGroups: [""]
  resources:  ["pods", "pods/attach", "pods/exec", "pods/portforward", "pods/proxy"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: [""]
  resources:  ["configmaps", "endpoints", "persistentvolumeclaims", "replicationcontrollers", "replicationcontrollers/scale", "secrets", "serviceaccounts", "services", "services/proxy"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: [""]
  resources:  ["events", "replicationcontrollers/status", "pods/log", "pods/status"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources:  ["daemonsets", "deployments", "deployments/rollback", "deployments/scale", "replicasets", "replicasets/scale", "statefulsets"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["autoscaling"]
  resources:  ["horizontalpodautoscalers"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["batch"]
  resources:  ["cronjobs", "jobs"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["extensions"]
  resources:  ["daemonsets", "deployments", "deployments/rollback", "deployments/scale","ingresses","replicasets", "replicasets/scale", "replicationcontrollers/scale"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["networking.k8s.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["servicecatalog.k8s.io"]
  resources:  ["clusterserviceclasses", "clusterserviceplans", "clusterservicebrokers", "serviceinstances", "servicebindings"]
  verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["servicecatalog.k8s.io"]
  resources:  ["clusterservicebrokers/status", "clusterserviceclasses/status", "clusterserviceplans/status", "serviceinstances/status", "serviceinstances/reference", "servicebindings/status",]
  verbs: ["update"]
- apiGroups: ["alicloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "get", "list", "patch", "update", "watch"]
- apiGroups: ["policy"]
  resources:  ["poddisruptionbudgets"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["networking.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["config.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["rbac.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["istio.alibabacloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["authentication.istio.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["log.alibabacloud.com"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["monitoring.kiali.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["kiali.io"]
  resources:  ["*"]
  verbs: ["create", "delete", "deletecollection", "get", "list", "patch", "update", "watch"]
- apiGroups: ["apiextensions.k8s.io"]
  resources: ["customresourcedefinitions"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["serving.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["eventing.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["messaging.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["sources.eventing.knative.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["tekton.dev"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]
- apiGroups: ["alert.alibabacloud.com"]
  resources: ["*"]
  verbs: ["get", "list", "create", "watch", "patch", "update", "delete", "deletecollection"]

Scenario 3: Permission administrator

A permission administrator manages RBAC authorization for other RAM users or RAM roles. By default, RAM users and RAM roles have no permission to grant RBAC permissions to others.

If a RAM user navigates to the Authorizations page in the Container Compute Service console and sees the message "The current RAM user account has no permission to manage authorizations. Contact the Alibaba Cloud account owner or authorized RAM user to request permission", that user is missing the required RAM or RBAC administrator permissions.

Step 1: Grant RAM permissions

The permission administrator needs RAM permissions to do all of the following:

List other RAM users or RAM roles
Attach RAM authorization policies to specified RAM users or RAM roles
View the Kubernetes RBAC permission configurations of specified RAM users or RAM roles
Perform Kubernetes RBAC authorization

Use the RAM console to attach a custom policy that includes these permissions. For instructions, see Grant RAM permissions to a RAM user or RAM role.

{
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
            "acc:DescribeCommodityStatus",
            "acc:CheckServiceRole",
            "acc:DescribeCloudProducts",
            "acc:DescribeRegions",
            "acc:DescribeZones",
            "acc:GetInstancePrice",
            "acc:RecommendZones"
           ],
            "Resource": "*"
      },
      {
         "Effect": "Allow",
         "Action": "bssapi:GetPayAsYouGoPrice",
         "Resource": "*"
      },
      {
            "Action": [
                "ram:Get*",
                "ram:List*",
                "cs:GetUserPermissions",
                "cs:GetSubUsers",
                "cs:GrantPermission",
                "cs:CheckServiceRole"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "ram:AttachPolicyToUser",
                "ram:AttachPolicyToRole"
            ],
            "Effect": "Allow",
            "Resource":  [
                "acs:ram:*:*:policy/xxxx",
                "acs:*:*:*:user/*"
            ]
        },
        {
            "Action": [
                 "vpc:ListEnhanhcedNatGatewayAvailableZones",
                 "vpc:DescribeEipAddresses"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "1"
}

In acs:ram:*:*:policy/xxxx, replace xxxx with the name of the RAM policy you want the administrator to be able to attach. If you use *, the administrator can attach any RAM policy.

Step 2: Grant RBAC permissions

In the Container Compute Service console, click Authorizations in the left navigation pane.
On the RAM Users or RAM Roles tab, find the authorization object and click Modify Permissions.
In the dialog box, click Add Permissions, set the role for the target cluster and namespace to Administrator or the cluster-admin custom role, and click Submit.

After you grant these RAM and RBAC permissions, the permission administrator can manage RBAC authorization for other RAM users or RAM roles within the defined scope. For more information, see Grant RAM permissions to a RAM user or RAM role.

Authorization actions reference

The following table describes the key authorization actions used in the policy examples above.

Action	Description
`acc:CheckServiceRole`	Checks whether the account has authorized the product to assume a ServiceRole to access cloud resources
`acc:DescribeCommodityStatus`	Checks whether ACS is activated for the account
`bssapi:GetPayAsYouGoPrice`	Queries pricing for pay-as-you-go products
`ram:ListUserBasicInfos`	Queries basic information for all RAM users
`ram:ListRoles`	Queries basic information for all RAM roles

1. For a full description of ACK authorization actions, see Authorization information. 2. Before writing authorization policies, follow the Principle of Least Privilege (PoLP) and verify supported actions in the product documentation. See Authorization information. 3. If you do not specify a target cluster ID and set the authorization scope to *, you grant permissions to operate on all ACK clusters, excluding ACS clusters. Grant these permissions with caution.