Grant permissions to the ALB Ingress Controller - Container Service for Kubernetes

The ALB Ingress Controller calls Application Load Balancer (ALB), Resource Access Management (RAM), Virtual Private Cloud (VPC), and Elastic Compute Service (ECS) API operations. In an ACK dedicated cluster, worker nodes have no cloud API permissions by default, so grant these permissions before deploying services exposed through ALB Ingress.

Prerequisites

Before you begin, ensure that the following conditions are met:

Usage notes

Grant permissions to the ALB Ingress Controller only in ACK dedicated clusters. In ACK managed clusters and ACK Serverless clusters, ALB Ingress is available without granting permissions to the ALB Ingress Controller.

Step 1: Create a custom RAM policy

Log on to the RAM console as a RAM user with administrative rights.
In the left navigation pane, choose Permissions > Policies.
On the Policies page, click Create Policy.
On the Create Policy page, click the JSON Editor tab.

The default policy template contains Version (set to "1") and a Statement array. Each statement contains Effect (default value: "Allow"), Action, Resource, and Condition. Specify the required actions and resources in Action and Resource.

Replace the default content with the following policy document, then click OK.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "alb:EnableLoadBalancerIpv6Internet",
                "alb:DisableLoadBalancerIpv6Internet",
                "alb:CreateAcl",
                "alb:DeleteAcl",
                "alb:ListAcls",
                "alb:ListAclRelations",
                "alb:AddEntriesToAcl",
                "alb:AssociateAclsWithListener",
                "alb:ListAclEntries",
                "alb:RemoveEntriesFromAcl",
                "alb:DissociateAclsFromListener",
                "alb:TagResources",
                "alb:UnTagResources",
                "alb:ListServerGroups",
                "alb:ListServerGroupServers",
                "alb:AddServersToServerGroup",
                "alb:RemoveServersFromServerGroup",
                "alb:ReplaceServersInServerGroup",
                "alb:CreateLoadBalancer",
                "alb:DeleteLoadBalancer",
                "alb:UpdateLoadBalancerAttribute",
                "alb:UpdateLoadBalancerEdition",
                "alb:EnableLoadBalancerAccessLog",
                "alb:DisableLoadBalancerAccessLog",
                "alb:EnableDeletionProtection",
                "alb:DisableDeletionProtection",
                "alb:ListLoadBalancers",
                "alb:GetLoadBalancerAttribute",
                "alb:ListListeners",
                "alb:CreateListener",
                "alb:GetListenerAttribute",
                "alb:UpdateListenerAttribute",
                "alb:ListListenerCertificates",
                "alb:AssociateAdditionalCertificatesWithListener",
                "alb:DissociateAdditionalCertificatesFromListener",
                "alb:DeleteListener",
                "alb:CreateRule",
                "alb:DeleteRule",
                "alb:UpdateRuleAttribute",
                "alb:CreateRules",
                "alb:UpdateRulesAttribute",
                "alb:DeleteRules",
                "alb:ListRules",
                "alb:UpdateListenerLogConfig",
                "alb:CreateServerGroup",
                "alb:DeleteServerGroup",
                "alb:UpdateServerGroupAttribute",
                "alb:UpdateLoadBalancerAddressTypeConfig",
                "alb:AttachCommonBandwidthPackageToLoadBalancer",
                "alb:DetachCommonBandwidthPackageFromLoadBalancer",
                "alb:UpdateServerGroupServersAttribute",
                "alb:MoveResourceGroup",
                "alb:DescribeZones",
                "alb:ListAScripts",
                "alb:CreateAScripts",
                "alb:UpdateAScripts",
                "alb:DeleteAScripts"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ram:CreateServiceLinkedRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "ram:ServiceName": [
                        "alb.aliyuncs.com",
                        "audit.log.aliyuncs.com",
                        "nlb.aliyuncs.com",
                        "logdelivery.alb.aliyuncs.com"
                    ]
                }
            }
        },
        {
            "Action": [
                "log:GetProductDataCollection",
                "log:OpenProductDataCollection",
                "log:CloseProductDataCollection"
            ],
            "Resource": "acs:log:*:*:project/*/logstore/alb_*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "yundun-cert:DescribeSSLCertificateList",
                "yundun-cert:DescribeSSLCertificatePublicKeyDetail",
                "yundun-cert:CreateSSLCertificateWithName",
                "yundun-cert:DeleteSSLCertificate"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "vpc:DescribeVSwitches",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ecs:DescribeNetworkInterfaces",
            "Resource": "*",
            "Effect": "Allow"
        }
    ]
}

Separate multiple policy documents with commas (,).

In the Create Policy dialog box, enter a Policy Name and Description, then click OK.

Step 2: Attach the policy to the worker RAM role

Log on to the ACK console. In the left navigation pane, click Clusters.
On the Clusters page, click the name of your cluster, then click the Basic Information tab.
On the Basic Information tab, click the link to the right of Worker RAM Role to open the RAM console.
On the Permissions tab, click Attach Policy. In the Attach Policy panel, in the Policies section, filter and select the custom policy created in the previous step.
Click OK.
Click Close.

Step 3: Verify the instance RAM role

In the left navigation pane of the cluster details page, choose Nodes > Nodes.
On the Nodes page, click the instance ID of a worker node—for example, i-2ze5d2qi9iy90pzb****.
On the instance details page, click the Instance Details tab. In the Other Information section, check whether a RAM role is displayed next to RAM Role. If no RAM role is attached, attach one to the ECS instance. For more information, see Detach or change an instance RAM role.

Step 4: Restart the ALB Ingress Controller pod

Important

Perform this step during off-peak hours.

Restart the alb-ingress-controller pod to ensure that the add-on works properly.

Get the pod name.

kubectl -n kube-system get pod | grep alb-ingress-controller

Expected output:

NAME                          READY   STATUS    RESTARTS   AGE
alb-ingress-controller-***    1/1     Running   0          60s

Delete the pod. Replace alb-ingress-controller-*** with the name from the previous step.
```
kubectl -n kube-system delete pod alb-ingress-controller-***
```
Expected output:
```
pod "alb-ingress-controller-***" deleted
```
After a few minutes, confirm the pod is running again.
```
kubectl -n kube-system get pod
```
Expected output:
```
NAME                           READY   STATUS    RESTARTS   AGE
alb-ingress-controller-***2    1/1     Running   0          60s
```
A Running status confirms the ALB Ingress Controller is working correctly with the new permissions.

What's next

To route traffic to services in your cluster using ALB Ingress, see Expose services with an ALB Ingress.