Container Compute Service (ACS) uses two authorization layers: Resource Access Management (RAM) for cloud resource operations and role-based access control (RBAC) for Kubernetes resources inside clusters. A RAM user or RAM role needs permissions from both layers to manage clusters and workloads.
| Task | Authorization layer | Documentation |
|---|---|---|
| Create, view, or delete clusters | RAM | Grant permissions to a RAM user or RAM role |
| Grant a team member access to pods, Deployments, or Services | RAM + RBAC | Grant RBAC permissions to RAM users or RAM roles |
| Let different pods access different cloud services | RAM (RRSA) | Use RRSA to authorize pods to access cloud services |
| Set up an O&M engineer with cluster and application access | RAM + RBAC | Scenario 1: Grant O&M engineers the permissions to manage clusters and applications |
| Set up a developer with namespace-scoped access | RAM + RBAC | Scenario 2: Grant developers the permissions to manage your clusters and applications |
| Delegate permission management to an administrator | RAM + RBAC | Scenario 3: Grant authorization administrators the permissions to manage the permissions of RAM users and RAM roles |
How the two layers work together
ACS clusters are a type of Container Service for Kubernetes (ACK) Serverless cluster. All cluster management calls ACK APIs, so both cloud-level (RAM) and cluster-level (RBAC) permissions must be in place.
| Layer | Scope | Controls | Granted through |
|---|---|---|---|
| RAM authorization | Cloud resources (control plane) | Cluster lifecycle, RBAC management, monitoring, logs, and events | RAM system policies or custom policies |
| RBAC authorization | Kubernetes resources (data plane) | Workloads, networking, storage, namespaces, ConfigMaps, and Secrets | Predefined or custom ClusterRoles in the ACS console |
Complete RAM authorization before granting RBAC permissions.
What RAM authorization covers
RAM authorization grants permissions for cluster O&M operations:
-
Create, view, and delete clusters
-
Manage RBAC authorization
-
Monitor clusters and manage logs and events
What RBAC authorization covers
RBAC authorization grants namespace-level or cluster-wide permissions on Kubernetes resources:
-
Workload resources: Deployment, StatefulSet, Job, CronJob, pod, ReplicaSet, and HorizontalPodAutoscaler (HPA)
-
Network resources: Service, Ingress, and NetworkPolicy
-
Storage resources: persistent volume (PV), persistent volume claim (PVC), and StorageClass
-
Other resources: Namespace, ConfigMap, and Secret
RAM authorization
By default, RAM users and RAM roles cannot call cloud service APIs. Attach RAM policies to grant the required access.
System policies
System policies grant broad, predefined permissions suited for O&M access across all clusters in an account. Grant permissions to a RAM user or RAM role.
| System policy | What it grants | Scope note |
|---|---|---|
| AliyunCSFullAccess | Full access to all ACK API operations | Includes all ACK clusters, not just ACS clusters. Does not grant RBAC permissions on Kubernetes resources. |
| AliyunCSReadOnlyAccess | Read-only access to all ACK API operations | Includes all ACK clusters, not just ACS clusters. |
| AliyunACCFullAccess | Full access to all ACS API operations | ACS clusters only. |
| AliyunACCReadOnlyAccess | Read-only access to all ACS API operations | ACS clusters only. |
| AliyunVPCReadOnlyAccess | Read-only access to Virtual Private Cloud (VPC) | Required to select a VPC when creating an ACS cluster. |
| AliyunContainerRegistryFullAccess | Full access to container images in Container Registry (ACR) | Account-wide. |
| AliyunLogReadOnlyAccess | Read-only access to Simple Log Service (SLS) | Required to select a log project for audit logs or view configuration inspection results. |
| AliyunRAMFullAccess | Full access to RAM | Required to manage authorization for other RAM users and RAM roles. |
| AliyunEBSFullAccess | Full access to Elastic Block Storage (EBS) | Required to use disk storage features. |
| AliyunARMSReadOnlyAccess | Read-only access to Application Real-Time Monitoring Service (ARMS) | Required to view Managed Service for Prometheus monitoring data. |
| AliyunKMSReadOnlyAccess | Read-only access to Key Management Service (KMS) | Required to select encryption keys when creating an ACS cluster. |
AliyunCSFullAccess and AliyunCSReadOnlyAccess cover all ACK clusters, not just ACS clusters. Evaluate whether this scope is appropriate before attaching these policies.
Custom policies
Custom policies provide fine-grained control over specific API operations and resources. Use them when RAM users or RAM roles need narrowly scoped permissions for SDK-based development.
The following example grants read-only access to an Object Storage Service (OSS) bucket named myphotos:
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:ListBuckets",
"oss:GetBucketStat",
"oss:GetBucketInfo",
"oss:GetBucketTagging",
"oss:GetBucketAcl"
],
"Resource": "acs:oss:*:*:*"
},
{
"Effect": "Allow",
"Action": [
"oss:ListObjects",
"oss:GetBucketAcl"
],
"Resource": "acs:oss:*:*:myphotos"
},
{
"Effect": "Allow",
"Action": [
"oss:GetObject",
"oss:GetObjectAcl"
],
"Resource": "acs:oss:*:*:myphotos/*"
}
]
}Pod-level access with RRSA
RAM Roles for Service Accounts (RRSA) associates a RAM role with a Kubernetes ServiceAccount so that pods using that ServiceAccount can call designated cloud service APIs. Use RRSA to authorize different pods to access different cloud services.
RBAC authorization
After RAM authorization is in place, grant RBAC permissions to control what a RAM user or RAM role can do with Kubernetes resources. Assign RBAC permissions from the ACS console authorization page.
Predefined roles
ACS provides the following predefined roles plus a custom option. Each maps to a ClusterRole. Grant RBAC permissions to RAM users or RAM roles.
| Role | Scope | Grants | Does not grant |
|---|---|---|---|
| Administrator | All namespaces | Read and write access to all resources | -- |
| O&M engineer | All namespaces | Read and write access to console-visible resources; read-only access to nodes, PVs, namespaces, and quotas | Write access to nodes, PVs, namespaces, and quotas |
| Developer | Specified or all namespaces | Read and write access to console-visible resources | Access outside the assigned namespace (when namespace-scoped) |
| Restricted user | Specified or all namespaces | Read-only access to console-visible resources | Write access to any resource |
| Custom role | Defined by ClusterRole | Determined by the selected ClusterRole | Permissions not included in the ClusterRole |
Before assigning a custom role, review the ClusterRole permissions to verify that only the required access is granted. Customize an RBAC role.
Roles and ClusterRoles
Kubernetes RBAC uses two types of role resources:
-
Role -- a namespaced resource that defines permissions within a single namespace. Specify the target namespace when creating a Role.
-
ClusterRole -- a non-namespaced resource that defines cluster-wide permissions.
A ClusterRole can be used in three ways:
-
Grant permissions on namespaced resources within individual namespaces.
-
Grant permissions on namespaced resources across all namespaces.
-
Grant permissions on cluster-scoped resources.
Use a Role when permissions should be limited to one namespace. Use a ClusterRole when permissions span the entire cluster.
ACK allows only ClusterRoles to grant RBAC permissions. Roles cannot be used for RBAC authorization.
To create a custom ClusterRole, see Customize an RBAC role. To attach a ClusterRole to a RAM user or RAM role, see Grant RBAC permissions to RAM users or RAM roles.