Check what external resources is used by current AKS security principal#

In some scenarios, you may want to use external resources, such as: public IP resources, storage accounts outside of the Node Resource Group (NRG), or custom VNet for AKS. Assigning roles to the new managed identity with the same permissions on these resources is required to ensure that AKS can continue to use them after changing the security principal.

1. Get current AKS security principal object ID

aksIdentityType=$(az aks show -n ${aks} -g ${rG} \
--query identity.type -o tsv)

if [[ "$aksIdentityType" == "SystemAssigned" ]]
then
aksIdentityId=$(az aks show -n ${aks} -g ${rG} \
--query identity.principalId -o tsv)
fi
if [[ "$aksIdentityType" == "UserAssigned" ]]
then
aksIdentityId=$(az aks show -n ${aks} -g ${rG} \
--query identity.userAssignedIdentities.*.principalId -o tsv)
fi
if [[ "$aksIdentityType" == "" ]]
then
aksSPclientId=$(az aks show -n ${aks} -g ${rG} \
--query servicePrincipalProfile.clientId -o tsv)
aksIdentityId=$(az ad sp show \
--id ${aksSPclientId} --query id -o tsv)
fi

oldaksIdentityId=${aksIdentityId}

2. Check role assignments for current AKS security principal, excluding the scope of the AKS Node Resource Group (NRG)

aksNrgId=$(az group show --query id -o tsv \
-n $(az aks show -n ${aks} -g ${rG} \
--query nodeResourceGroup -o tsv))

assignmentList=$(az role assignment list --all --query \
"[?principalId=='${aksIdentityId}'&&"'!'"starts_with(scope,'${aksNrgId}')]. \
{roleId:roleDefinitionId,name:roleDefinitionName,scope:scope}")

echo ${assignmentList}

If there is no output, we can assume that AKS currently has no control on resources outside of the Node Resource Group (NRG).

NOTE

When changing the security identity used by AKS, it automatically grants permissions to the new managed identity on Node Resource Group (NRG). So you don’t need to consider permissions on resources in the Node Resource Group (NRG).

Preparing new user-assigned managed identity#

As mentioned above, to convert AKS cluster into private cluster, it must use user-assigned managed identity. Therefore, we will create a new user-assigned managed identity here and ensure that it inherits permissions from the current AKS security principal, excluding the scope of the Node Resource Group (NRG).

1. Create user-assigned managed identity

uami=${aks}-newIdentity
az identity create -n ${uami} -g ${rG} -o none
uamiId=$(az resource list -n ${uami} -g ${rG} \
--resource-type Microsoft.ManagedIdentity/userAssignedIdentities \
--query [0].id -o tsv)
uamiIdentityId=$(az identity show --ids $uamiId \
--query principalId -o tsv)

2. Have the new managed identity inherit permissions from current AKS security principal (Conditional skip)

NOTE

If the current AKS security principal has no control over resources outside of the Node Resource Group (NRG), you can skip this section.

assignmentNum=$(echo ${assignmentList} | jq length)
for ((i=0; i<${assignmentNum}; i++)); do 
  roleId=$(echo "${assignmentList}" | jq -r '.['$i'] | .roleId')
  scope=$(echo "${assignmentList}" | jq -r '.['$i'] | .scope')
  
  az role assignment create --role ${roleId} \
  --assignee-object-id ${uamiIdentityId} -o none\
  --scope ${scope} --assignee-principal-type ServicePrincipal
done

Update current AKS cluster to use new user-assigned managed identity#

After all the preparation, we can migrate the current AKS security principal to the new user-assigned managed identity.

az aks update -n ${aks} -g ${rG} -o none \
--enable-managed-identity --assign-identity ${uamiId}

NOTE

This process DOES NOT automatically rotate the nodes.
If you were using system-assigned managed identity, the old system-assigned identity will be deleted.

CAUTION

If the current type of AKS security principal is service princial, there might be no going back. Check the note in Use a managed identity in Azure Kubernetes Service (AKS).
The process of converting your current AKS cluster to a private cluster will naturally resolve the old and new security principal conflicts, as node rotation occurs during the process. However, if you use AKS to pull images from ACR, you will need to re-grant permissions.

Re-grant permission to access ACR (Conditional skip)#

NOTE

If the AKS is using a system-assigned managed identity, skip this section.

This procedure is required for AKS which was using service principal, or after converting an AKS cluster to a private cluster, your workloads will fail. If you do not have any Azure Container Registry (ACR) resources, you can also skip this step.

Since we are now using managed identities, AKS now relies on the kubelet managed identity to access the Azure Container Registry (ACR). This managed identity is different from the managed identity we just created. These two identities can be the same, but we won’t discuss that here.

1. Check current ACR resources in your subscription

az resource list --resource-type Microsoft.ContainerRegistry/registries \
--query "[].{name:name,id:id}" -o yaml

2. Re-attach ACR back to AKS

az aks update -n ${aks} -g ${rG} --attach-acr {ACR_name/ID}

NOTE

This also applies to scenarios where you use managed identities to access storage accounts without access keys, or likewise. You will need to re-configure them to ensure they have access after a node rotation.