ASK can't pull image from ACR, always fails with 401 unauthorized error

Question

ASK can't pull image from ACR, always fails with 401 unauthorized error

Rodolfo Silva 20

Hello,

I need help with a persistent 401 Unauthorized error when my AKS cluster tries to pull an image from an Azure Container Registry (ACR) from a different resource group (same subscription).

Whenever the cluster pulls the image from the ACR, it fails with a "Failed to pull image" error and the 401 Unauthorized code. This happens even when bypassing the image's specific tag or when pulling it directly by the it's digest (@sha256:...), with the same format: failed to authorize: failed to fetch anonymous token: unexpected status from GET request to https://<acr-name>/oauth2/token?scope=...

Some verification steps conducted were:

RBAC Verification: it was confirmed that the AKS cluster's Kubelet Managed Identity (identityProfile.kubeletidentity.objectId) has the AcrPull role assigned correctly on the ACR's scope;
Kubernetes Configuration: it was verified that the pod specification does not use imagePullSecrets;
ACR Policies: it was checked that the ACR's Content Trust policy and confirmed it is disabled;
ACR Networking: it was checked that the ACR's networkRuleSet and confirmed it is at the default setting (public access is enabled and no firewall rules are configured);
Tag vs. Digest: it was attempted to pull the image using both its specific tag name and its unique digest (@sha256:...). Both methods failed with the exact same 401 Unauthorized error.

Are there any missing configurations to be checked or set?

Thank you in advance.

0 comments

Answer accepted by question author

Manish Deshpande 8,215 Microsoft External Staff Moderator

Hi @Rodolfo Silva

Thanks for the very detailed write-up you've already ruled out the common culprits (AcrPull assignment, no imagePullSecrets, Content Trust off, public network access on), which genuinely narrows this down.

First, the reassuring part: the ACR being in a different resource group is not the cause. AKS authenticates to ACR using the kubelet managed identity's Microsoft Entra object, so resource-group boundaries within the same subscription are irrelevant to this.

One important clue: your error says failed to fetch **anonymous** token. AKS always first attempts an anonymous pull and only falls back to authenticated pull — so this specific wording often points to either an authorization model mismatch (ABAC), an image-reference problem, or an architecture mismatch, rather than a plain missing role. I'd suggest working through the steps below in order.

1) Confirm whether your registry is ABAC-enabled (most likely cause given your symptoms)

If your ACR is in "RBAC Registry + ABAC Repository Permissions" mode, the classic AcrPull role is not honored — which perfectly explains a 401 even though AcrPull "looks correct."

In the portal: Container registry → Properties / Access control → check the Role assignment permissions mode.
If it's ABAC-enabled, assign the Container Registry Repository Reader role to the kubelet identity instead of AcrPull.
⚠️ Note: az aks update --attach-acr does not support ABAC registries — you must assign the role manually (portal or az role assignment create).

Reference: https://learn.microsoft.com/en-us/azure/container-registry/container-registry-rbac-abac-repository-permissions?tabs=azure-portal

2) Validate the exact image reference

Because the error is the anonymous-token variant, an incorrect image path can produce this exact 401. Please double-check:

Login server is <acr-name>.azurecr.io (a common typo is azureacr.io).
Registry name, repository name, and tag/digest are all correct.

3) If the registry is not ABAC-enabled, re-run the attach to reconcile the integration

az aks update -n <aks-cluster> -g <aks-rg> --attach-acr <acr-resource-id>

Use the full ACR resource ID (not just the name), since the registry is in another resource group.

4) Confirm the kubelet identity is actually bound to the node VMSS

This is a very common cause of your exact symptom. Get the kubelet identity, then verify it's present on the node scale set:

az aks show -g <aks-rg> -n <aks-cluster> --query identityProfile.kubeletidentity
az vmss identity show -g <node-resource-group> -n <aks-vmss-name>

AKS never removes the kubelet identity from the VMSS on its own, so if it's missing it was removed out-of-band. Re-attaching (step 3) restores it. If a plain reconcile is needed: az aks update -g <aks-rg> -n <aks-cluster>.

5) Run the built-in end-to-end check

az aks check-acr -n <aks-cluster> -g <aks-rg> --acr <acr-name>.azurecr.io

This validates DNS, routing, and pull permission together.

6) Rule out an architecture (ARM64 vs AMD64) mismatch

An image/node architecture mismatch surfaces this identical anonymous token 401 (it really means "no matching platform in manifest"). If az aks check-acr returns exec /canipull: exec format error, that confirms a mismatch. Verify:

az acr manifest list-metadata --registry <acr-name> --name <repo> --query "[].architecture"

7) If AcrPull was granted via a Microsoft Entra group

There can be a propagation delay before group-based RBAC takes effect. If you assigned AcrPull to a group rather than directly to the kubelet identity, try assigning the role directly to the kubelet identity to rule this out.

Links for reference:

https://learn.microsoft.com/en-us/troubleshoot/azure/azure-kubernetes/connectivity/cannot-pull-image-from-acr-to-aks-cluster

https://learn.microsoft.com/en-us/azure/aks/cluster-container-registry-integration?pivots=azure-cli
https://learn.microsoft.com/en-us/azure/container-registry/container-registry-rbac-abac-repository-permissions?tabs=azure-portal

If you have any questions please feel free to comment in the comment section with the ask i will be happy to assist you further.

Thanks,
Manish.

Manish Deshpande 8,215 Reputation points Microsoft External Staff Moderator

2026-06-22T10:18:12.4866667+00:00

Hello @Rodolfo Silva

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Rodolfo Silva 20 Reputation points

2026-06-22T10:42:31.5366667+00:00
There were actually 2 problems:

The cluster wasn't granted access to the acr via azure cli. It was solved by assigning directly through azure portal;

The VMs had the arm64 architecture, while the image was amd64.

Thank you, Manish

1 additional answer

Your answer

Manish Deshpande 8,215 Reputation points Microsoft External Staff Moderator

2026-06-22T10:18:12.4866667+00:00

Hello @Rodolfo Silva

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.
Rodolfo Silva 20 Reputation points

2026-06-22T10:42:31.5366667+00:00

There were actually 2 problems:

The cluster wasn't granted access to the acr via azure cli. It was solved by assigning directly through azure portal;

The VMs had the arm64 architecture, while the image was amd64.

Thank you, Manish

Answer 1

Honestly, looking at everything you've already checked, the most likely culprit is one of these three:**

The --attach-acr command hasn't been run** Even if the role assignment looks right manually, cross-resource-group ACR pulls often need the official AKS-ACR attach to reconcile properly. Just run:

bash

az aks update --resource-group <aks-rg> --name <aks-cluster> --attach-acr <acr-name>

This single command fixes the majority of cases like yours.

2. The role is assigned at the wrong scope You confirmed AcrPull is assigned, but it might be on the resource group rather than the ACR resource itself. Those are different things and it's an easy mistake to make. Double check that the scope ends with .../registries/<acr-name> not just the resource group.

3. The Kubelet identity isn't what the node pool is actually using: This happens more than people realize, especially after cluster upgrades or identity changes. The identity in identityProfile.kubeletidentity and what the nodes are actually running with can get out of sync without any obvious warning.

Honestly I'd start with number one. It's one command, takes 30 seconds, and resolves this specific cross-resource-group scenario more often than not. If that doesn't fix it, then dig into the scope verification.