unauthorized webapp vnet integrated and container registry with private endpoint

Question

hello guys,

This is a duplicate post with the same ID. For some reason, the original question I posted seems to have a bug that prevents me from viewing it.

I have a Linux-based web app with VNet integration enabled, configured with an IP address space and a /29 subnet for the IP range. Additionally, I have an Azure Container Registry (ACR) with private access enabled and a private endpoint established within a dedicated VNet also using /29 subnet. The web app is also configured to use a system-assigned identity, which has been granted the AcrPull permission to the ACR IAM.

The challenge arises when I try to connect to the ACR from the web app's Kudu Bash using the command curl -v https://nonprodacr.azurecr.io/v2/. The response shows that the ACR endpoint is resolvable, but further down, it indicates an 'unauthorized' error. I suspect this might be related to IDMS (Identity Management Service) access. However, to my understanding, the default IDMS server should automatically be accessible within Azure infrastructure. I haven’t encountered this issue before with other web apps that have VNet integration enabled.

To provide a clearer picture of the services, I am sharing some of the configurations and test results I performed. Any guidance or advice on resolving this issue would be greatly appreciated.

kudu bash result:

WebApp networking configuration:

IP restriction: enabled with specified IPs for internal access

VNet integration: below screenshot

NSGs configuration: screenshot

Answer 1

Hello Emmanuel !

Thank you for posting on MS Learn Q&A.

I saw that you had some feedback so I will add my assumptions that were not mentioned above.

The curl -v https://<acr>.azurecr.io/v2/ result does not necessarily prove a failure. A 401 Unauthorized from /v2/ is expected when no Docker/ACR bearer token is provided. It means the app reached the ACR endpoint and ACR challenged for authentication. Kudu curl does not automatically use the Web App managed identity.

The more important point is that the hostname appears to resolve to a public ACR IP (20.x.x.x). If the ACR is meant to be accessed through Private Endpoint, from the Web App/Kudu console the ACR FQDN should resolve to the private endpoint IP. I would first validate DNS:

nslookup <acr-name>.azurecr.io
nslookup <acr-name>.<region>.data.azurecr.io

If it resolves publicly, link the privatelink.azurecr.io private DNS zone to the VNet used by the Web App VNet integration or configure the custom DNS forwarder correctly. ACR private endpoint requires DNS records for the registry endpoint and data endpoint.

For the actual image pull, also verify that the Web App is explicitly configured to use managed identity for ACR and that image pull traffic is routed through the VNet:

az webapp config set \
  --resource-group <rg> \
  --name <app-name> \
  --generic-configurations '{"acrUseManagedIdentityCreds": true}'
az resource update \
  --resource-group <rg> \
  --name <app-name> \
  --resource-type "Microsoft.Web/sites" \
  --set properties.outboundVnetRouting.imagePullTraffic=true

The managed identity must have AcrPull on the registry, and for a network-protected registry App Service also needs VNet integration, private endpoint DNS resolution, and image-pull-over-VNet enabled.

I have a concern about the VNet integration subnet it looks very small and App Service VNet integration requires at least /28 for an existing subnet and it is recommended to use /26 to avoid issues during scale operations or platform upgrades. A /29 subnet with only a couple of free IPs can cause unstable behavior.