AKS cannot pull from private ABAC-enabled ACR: 401 persists after correct kubelet roles, reconcile, node-image refresh, and pull secret

I have a private AKS cluster in Central US and a private Azure Container Registry with public network access disabled. The registry uses “RBAC Registry + ABAC Repository Permissions.”

A one-time Job cannot pull this immutable image:

<private-registry>.azurecr.io/estate-planning/worker@sha256:4e3de791d211ae13dc1ea387d095518aaca321b0df1c7ba00d60b13d24fba187

The Job schedules successfully but never starts its container. Pod events repeatedly show:

failed to pull and unpack image ... failed to resolve image ...

failed to authorize: failed to fetch anonymous token:

unexpected status from GET request to

https://<private-registry>.azurecr.io/oauth2/token?scope=repository%3Aestate-planning%2Fworker%3Apull&service=<private-registry>.azurecr.io:

401 Unauthorized

Configuration verified:

• AKS uses a user-assigned kubelet managed identity.
• That exact kubelet identity is attached to the system VM scale set.
• The identity has:
  • Container Registry Repository Reader, restricted by ABAC condition to estate-planning/worker
  • Container Registry Repository Catalog Lister
• The ACR private endpoint is approved and private DNS is linked.
• The image is built as linux/amd64; the AKS Linux system pool uses Standard_D2s_v6.
• The verification service account has no pre-existing imagePullSecret.

Troubleshooting already completed:

1. Reconciled AKS after confirming the ABAC role assignments.
2. Performed a node-image-only upgrade of the existing system pool.
3. Retried the pull after each step; the same 401 occurred.
4. Created a temporary ACR token restricted to estate-planning/worker with only content/read and metadata/read.
5. Created a temporary kubernetes.io/dockerconfigjson imagePullSecret and referenced it only in one retry Job.
6. That retry still reported the same anonymous-token 401.
7. All retry Jobs, temporary secrets, tokens, scope maps, and temporary namespace Writer permissions were deleted afterward.

No client or production data was accessed, and no persistent workload was deployed.

Questions:

1. Is this a known AKS + private ABAC-enabled ACR authentication issue?
2. Why does AKS report an anonymous-token request even when the pod specifies a valid repository-scoped imagePullSecret?
3. What supported, least-privilege diagnostic can verify whether this digest is retrievable from the private registry without introducing a VM or broad registry access?
4. Are there known constraints for AKS pulling by immutable digest from an ABAC-enabled private ACR?