Restrict worker RAM role permissions
Restrict the permissions of the Resource Access Management (RAM) role assigned to worker nodes based on the principle of least privilege to improve the security of your ACK managed clusters.
Modifying RAM policies can cause application or add-on failures if required permissions are removed. Test in a staging environment before applying changes to production.
Prerequisites
Before you begin, make sure that you have:
An ACK managed cluster (Pro or Basic) running Kubernetes 1.18 or later. Create an ACK managed cluster or manually upgrade a cluster if needed. Alternatively, migrate an ACK dedicated cluster to an ACK managed Pro cluster.
Granted the default service roles required by the ACK managed cluster. For more information, see Grant permissions to service roles.
Step 1: Assess current permissions
Determine whether the worker RAM role has excess permissions that need to be restricted.
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster. On the Basic Information tab, click the link next to Worker RAM Role.
In the RAM console, go to the Permissions tab of the Role page.
If there are no policies attached, no further action is needed. The worker RAM role has no extra permissions.
If policies are attached (for example,
k8sWorkerRolePolicy-db8ad5c7***), the role may have more permissions than necessary. Evaluate against your business needs based on the principle of least privilege, then proceed to the next step.
Review each attached policy to identify the Alibaba Cloud API actions it grants. This establishes a baseline before you make changes.
Step 2: Upgrade add-ons
Historically, ACK add-ons relied on the node's worker RAM role for cloud resource access. Current ACK add-ons use token-based authentication (managed service roles) instead. Upgrade your cluster add-ons and analyze audit logs to remove unnecessary permissions from the worker RAM role and limit the impact of potential security incidents.
Upgrade add-ons one at a time. Confirm that each upgrade succeeds before starting the next. Read the remarks for each add-on before upgrading.
For more information, see Manage add-ons.
Add-ons installed through Add-ons
On the Add-ons page, upgrade each installed add-on to at least the minimum version shown below. For add-ons that are already at or above the minimum version, redeploy them with the command listed in the table, or redeploy them through the console.
Monitoring and observability
Add-on | Minimum version | Redeploy command | Notes |
| v0.3.9.4-ff225cd-aliyun |
| None |
| v1.5.5 |
| None |
| 1.1.11 |
| None |
| 1.0.10 |
| Before upgrading, grant permissions for the managed cost role. |
| 1.2.16 |
| None |
Networking
Add-on | Minimum version | Redeploy command | Notes |
| v1.0.10.333-gfd2b7b8-aliyun |
| Upgrade the Terway according to your cluster's Terway mode. For more information, see Use the Terway network plug-in. After upgrading, check the Terway configuration. |
| v1.0.10.333-gfd2b7b8-aliyun |
| See remarks for |
| v1.0.10.333-gfd2b7b8-aliyun |
| See remarks for |
| v1.2.1 |
| None |
| 1.1.5 |
| Before upgrading, grant permissions for the managed Microservices Engine (MSE) role. |
Storage
Add-on | Minimum version | Redeploy command | Notes |
| v1.18.8.45-1c5d2cd1-aliyun |
| None |
| v1.18.8.45-1c5d2cd1-aliyun |
| None |
| v1.18.8.55-e398ce5-aliyun |
| None |
| v1.14.8.51-842f0a81-aliyun |
| None |
| v1.14.8.109-649dc5a-aliyun |
|
Logging
Add-on | Minimum version | Redeploy command | Notes |
| v1.0.29.1-0550501-aliyun |
| None |
| v3.0.2 |
| None |
Security and image management
Add-on | Minimum version | Redeploy command | Notes |
| v23.02.06.2-74e2172-aliyun |
| Before upgrading, grant permissions for the managed Container Registry (ACR) role. If you do not have custom RAM permissions and do not need to pull images across accounts, go to Add-ons and set tokenMode to managedRole. If you do not need credential-free image pulling for private images, uninstall this add-on. |
| 3.0.11 |
| Before upgrading, grant permissions for the managed MSE role. |
Cluster Autoscaler (installed through a node pool)
Add-on | Minimum version | Redeploy command | Notes |
| v1.3.1-bcf13de9-aliyun |
| To check the current version, use either method:
|
Check the Terway configuration
If your cluster has terway, terway-eni, or terway-eniip installed, verify that the Terway ConfigMap contains the correct credential path.
Run the following command to edit the Terway ConfigMap:
kubectl edit cm eni-config -n kube-systemIn the
eni_confsection, check for the following line:"credential_path": "/var/addon/token-config",If this line is present, no change is needed.
If this line is missing, add it below the
min_pool_sizeconfiguration.
Redeploy the Terway workload by running the corresponding redeploy command from the networking table above.
Step 3: Collect audit logs
Set up audit logging to track which Alibaba Cloud API operations the worker RAM role performs. This data tells you which permissions are still in use and which can be safely removed.
Collect audit logs for at least one week.
Log on to the ActionTrail console.
Create a single-account trail for the region where the cluster is located. When creating the trail, select Delivery to Log Service. For more information, see Create a single-account trail.
For the full list of services that ActionTrail supports, see Supported Alibaba Cloud services.
Step 4: Test cluster features
After upgrading add-ons and redeploying workloads, verify that core cluster features still work correctly.
Category | Test case | Reference |
Compute | Scale nodes out and in. | |
Network | Verify that IP addresses are assigned to pods. | |
Storage | Deploy workloads that use external storage (if applicable). | |
Monitoring | Confirm that monitoring and alert data is available. | |
Elasticity | Trigger node autoscaling (if applicable). | |
Security | Pull a private image without credentials (if applicable). | Use the aliyun-acr-credential-helper to pull images without using a secret |
In addition to the tests above, test the business logic of the applications deployed in your cluster.
Step 5: Analyze audit logs
After collecting logs for at least one week, query the data to identify which API operations the worker RAM role performed.
Log on to the Simple Log Service (SLS) console.
In the Projects section, click the project you specified in Step 3.

On the tab, click the destination Logstore. The Logstore is named
actiontrail_<trail_name>.Run the following query to list the API operations called through the Security Token Service (STS) token of the worker RAM role. Replace
<worker_role_name>with the name of the worker RAM role for your cluster. The results show which Alibaba Cloud services and API operations are being called. Use this data in Step 6 to decide which permissions to keep and which to remove.* and event.userIdentity.userName: <worker_role_name> | select "event.serviceName", "event.eventName", count(*) as total GROUP BY "event.eventName", "event.serviceName"
Step 6: Remove unused permissions
Based on the audit log analysis, remove permissions that the worker RAM role does not need.
Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of the target cluster. On the Basic Information tab, click the link next to Worker RAM Role.
On the Permissions tab of the Role page, click the destination access policy to go to the Policy Content tab. Click Modify Policy.
ImportantBefore you modify the policy document, back it up. This lets you roll back the permission configuration if needed.
Delete unnecessary permissions based on the audit log analysis from Step 5. For example, delete the
Actionpermissions from the policy that were not invoked during your audit period. If the query returned no results, you can safely detach the entire policy from the role.Redeploy the workloads using the commands listed in Step 2.
Repeat Steps 4, 5, and 6 until the worker RAM role has only the minimum permissions required by the add-ons or applications.