unauthorized webapp vnet integrated and container registry with private endpoint

Emmanuel Gaid 41

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: User's image

WebApp networking configuration:

IP restriction: enabled with specified IPs for internal access

VNet integration: below screenshot

User's image

NSGs configuration: screenshot

User's image

Sai Krishna Katakam 1,710 Reputation points Microsoft Vendor

2025-01-13T06:55:39.86+00:00
Hi Emmanuel Gaid,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

The issue seems to be related to authentication between your Azure Web App and Azure Container Registry (ACR). Follow these steps to resolve it:

Make sure the system-assigned identity of the web app has the AcrPull role on the ACR.

Verify role assignment:

az role assignment list --assignee <web-app-client-id> --scope <acr-resource-id>

Assign role if missing:

az role assignment create --assignee <web-app-client-id> --role AcrPull --scope <acr-resource-id>

Verify the web app can access the IMDS endpoint:

curl -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com&api-version=2019-08-01"

If this fails, check for NSGs or UDRs blocking access to 169.254.169.254.

Test ACR private endpoint DNS resolution from the web app:

nslookup <acr-private-endpoint-dns>

If it fails, ensure the private DNS zone for the ACR is linked to the web app's VNet.

Test authentication manually:

curl -H "Authorization: Bearer $(curl -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com&api-version=2019-08-01" | jq -r '.access_token')" https://<acr-name>.azurecr.io/v2/

If this fails, recheck role assignments and IMDS access.

For more details, please refer to the below documentation:
Azure Instance Metadata Service
Azure Private Endpoint private DNS zone values

If the information is helpful, please consider by clicking the "Upvote" on the post.
Emmanuel Gaid 41 Reputation points

2025-01-15T00:30:28.9566667+00:00

Update: It's interesting that the Web App was able to consume the image from ACR, but I'm still encountering the same error on Kudu. It's quite puzzling. Do you guys have any idea why this might be happening and causing two different results?
Suresh Chikkam 0 Reputation points Microsoft Vendor

2025-02-07T11:48:26.3566667+00:00

Hi Emmanuel, Kudu Bash operates in a different context. It does not directly inherit the same managed identity context as the web app runtime. The failure indicates that the default IMDS endpoint is either inaccessible or not being used correctly in the Kudu environment.

Share via

unauthorized webapp vnet integrated and container registry with private endpoint

Your answer