Azure ACR proxying failing with 401 insufficient_scope

[ringerc]

Proxying of an Azure ACR repo is successfully authenticating with the token for GET /oauth2/token, but then fails with HTTP 401 for the HEAD /v2/repositoryhere/imagename/... request for the image itself.

The token is valid. Supplying an invalid token instead causes the GET /oauth2/token requests to fail with a HTTP 401.

---

A new azure token I can use just fine for local pulls, generated with

az acr login --only-show-errors --expose -n $ACRNAME | jq -r '.accessToken'

and injected as

acr_secret="$(az acr login --only-show-errors --expose -n $ACRNAME | jq -r '.accessToken')"
acr_username='00000000-0000-0000-0000-000000000000'
DEBUG=true
docker run --rm \
	--name docker_registry_proxy \
	--net kind \
	--detach \
	--hostname docker-registry-proxy \
	-p 0.0.0.0:3128:3128 \
	-p 0.0.0.0:8981:8081 \
	-e ENABLE_MANIFEST_CACHE=true \
	-v /home/craig/projects/EDB/UPM/upm-stack/edbpgai-bootstrap/docker_mirror_cache:/docker_mirror_cache \
	-v /home/craig/projects/EDB/UPM/upm-stack/edbpgai-bootstrap/docker_mirror_certs:/ca \
	-e REGISTRIES="registry.k8s.io gcr.io quay.io ${ACRNAME}.azurecr.io" \
	-e AUTH_REGISTRIES="${ACRNAME}.azurecr.io:${acr_username}:${acr_secret}" \
	${DEBUG+-e DEBUG=${DEBUG}} \
	"rpardini/docker-registry-proxy:latest-debug"

... will be accepted for the request to /oauth2/token

{"access_time":"05/Sep/2025:00:55:13 +0000","upstream_cache_status":"","method":"GET","uri":"/oauth2/token","request_type":"unknown","status":"200","bytes_sent":"2258","upstream_response_time":"0.696","host":"ACRNAME.azurecr.io","proxy_host":"ACRNAME.azurecr.io","upstream":"x.x.x.x:443"}

but then the HEAD /v2/repositoryhere/imagename/manifests/sha256:fff5dd93afcacca459f3d5d88fc24175b5acebd2b70fdf7133383fded859624f is rejected with

Www-Authenticate:	Bearer realm="https://ACRNAME.azurecr.io/oauth2/token",service="ACRNAME.azurecr.io",scope="repository:repositoryhere/imagename:pull",error="insufficient_scope"

(per mitm-proxy).

What's odd is that I can pull directly with docker pull with the same credential, or by injecting it as an image pull secret in to Kubernetes.

So there's presumably something different, somehow, about what docker-registry-proxy is making the request.

I'll update this if I find a solution.