Why is az acr build blocked by my firewall if the "Allow trusted Microsoft services" bypass is enabled?

Question

Hello,

We are experiencing an issue where our Azure Container Registry firewall is blocking the az acr build command, despite having the "Allow trusted Microsoft services" exception enabled. Our ACR is located in the West US 2 region.

Configuration:

• Our ACR has Public network access set to Enabled.
• The Network rule set (firewall) has a Default action of Deny.
• The Network rule bypass for AzureServices is active. We have verified this via the Azure Portal UI and a direct Azure CLI query.

The Problem:

When we run the az acr build command, it consistently fails with a firewall denial.

• Expected Behavior: The command should succeed, as ACR Tasks (which az acr build uses) is a documented trusted service.
• Actual Behavior: The command fails with the error: denied: client with IP '...' is not allowed access. CorrelationId: 6ab1e689-32d3-476f-ba1c-7bde93953d89

The Contradiction (Proof):

We can prove the configuration is correct, but the behavior is not. A direct API query using az acr show returns the following correct settings, yet the build is still blocked:

  "networkRuleBypassOptions": "AzureServices",
  "networkRuleSet": {
    "defaultAction": "Deny",
    "ipRules": []
  },
  "publicNetworkAccess": "Enabled",

Troubleshooting Steps Already Taken:

To ensure this is not a user error, we have already:

1. Verified the setting in both the Azure Portal and via the Azure CLI (az acr show).
2. Corrected our Terraform IaC to match the exact provider schema for this setting.
3. Used terraform apply -replace to completely destroy and recreate the ACR to eliminate any "stuck state."
4. Confirmed the issue persists on the brand-new, cleanly provisioned ACR.

This seems to be a platform issue where the network enforcement is not honoring the active configuration. Has anyone else encountered this, or is there another configuration we are missing?

Thank you.

Answer 1

Hello Durga,

We wanted to follow up as promised and confirm that we have successfully resolved the az acr build firewall issue. Your guidance was instrumental in our success.

The GitHub issue you linked (acr/issues/762) was the key. It correctly confirmed we were dealing with a platform-level behavior and not a simple configuration error on our part.

For the benefit of anyone else who finds this thread, we discovered the definitive root cause was a rule precedence conflict on the ACR firewall. Because our ACR has a private endpoint, the master publicNetworkAccess property was set to Disabled. This Disabled state was overriding all other firewall rules, including our attempts to set the defaultAction to Allow.

The final, successful workaround was a three-step process:

Force the firewall completely open with a single, atomic command: az acr update --name <our-acr> --public-network-enabled true --default-action Allow

Run the az acr build ... command, which now succeeded.

Immediately restore the maximum security posture: az acr update --name <our-acr> --public-network-enabled false --default-action Deny

We wouldn't have reached this correct, nuanced solution without your help pointing us in the right direction. Thank you again!

Andrew

Answer 2

Hello Durga,

Thank you for the incredibly fast and helpful response.

The GitHub issue you linked (acr/issues/762) is the key. It perfectly describes the behavior we are seeing and confirms our suspicion that this is a known design limitation. We appreciate you validating our findings.

Based on your recommendation, we will proceed with our workaround plan to build the image locally from a trusted agent and use docker push.

We will post an update here if that is successful. Thanks again for your help!

Answer 3

Hi Andrew Cuncannan (Admin)

Could you please check the below things:

• Even though you have enabled the "Allow trusted Microsoft services" option, it's worth verifying that the Azure service tags for ACR are correctly configured. Azure services use specific IP ranges, and sometimes these ranges can change. Ensure that the service tag for Azure Container Registry is included in your network rules.
• According to this GitHub issue, even with the trusted services exception enabled, ACR Tasks may still be blocked unless public access is fully open or private endpoints are used. This suggests a design limitation or inconsistency in how the trusted services bypass is enforced - https://github.com/Azure/acr/issues/762
• Build the image locally or in a CI agent. And use docker push to upload to ACR, this often works even when az acr build fails, as noted in the GitHub thread.
• If your build agent is running in a different Azure region or if it is using a dynamic IP address, it may not be recognized as a trusted service. Ensure that the build agent's IP address is within the allowed range for Azure services. You can check the current IP address of the build agent and compare it against the allowed IPs.
• As a temporary measure, you can try changing the network rule set to allow all traffic (set the default action to Allow) to see if the az acr build command succeeds. If it does, this will confirm that the issue is indeed related to the firewall settings.
• whitelisting the IP address range fixes this issue. This IP Address range is mentioned in here for the ACR. The use case and limitation of Allow trusted Microsoft services to access this container registry are explained here.

Refer to these documents:

• https://learn.microsoft.com/en-us/troubleshoot/azure/azure-container-registry/client-ip-address-not-allowed-access - Make sure that the built-in firewall for your container registry allows traffic to your device's IP address.
• https://docs.azure.cn/en-us/container-registry/allow-access-trusted-services
• https://learn.microsoft.com/en-us/azure/container-registry/container-registry-firewall-access-rules
• https://github.com/Azure/azure-cli/issues/27253

Hope this helps!

Please Let me know if you have any queries.